Tiny Core Linux
General TC => General TC Talk => Topic started by: GNUser on May 20, 2026, 11:04:47 AM
-
Hi Rich. I use your wonderful provides.sh that's part of the base system. I've noticed that tce/provides.db can be updated normally when I'm using the official mirror, but not when I'm using my local mirror.
I made a small edit to provides.sh (removed the -q flag from the zsync command) so that it's more verbose. I also changed my real domain to "mydomain.net" for privacy (I'll send you my real domain in a PM):
$ sh -x /usr/bin/provides.sh bin/go
+ . /etc/init.d/tc-functions
+ '[' -f /proc/cmdline ]
+ CMDLINE=
+ cat /proc/cmdline
+ CMDLINE=' BOOT_IMAGE=/boot/vmlinuz64 tce=sda1 opt=sda1 tz=EST+5EDT,M3.2.0/2,M11.1.0/2 syslog lang=en_US.UTF-8 user=bruno loglevel=0 host=blaptop multivt text wayland noembed'
+ echo -e '\r\033[K'
'
+ echo -e '\033[1;31m'
+ RED=''
+ echo -e '\033[1;32m'
+ GREEN=''
+ echo -e '\033[1;33m'
+ YELLOW=''
+ echo -e '\033[1;34m'
+ BLUE=''
+ echo -e '\033[1;35m'
+ MAGENTA=''
+ echo -e '\033[1;36m'
+ CYAN=''
+ echo -e '\033[1;37m'
+ WHITE=''
+ echo -e '\033[0;39m'
+ NORMAL=''
+ useBusybox
+ alias 'ar=busybox ar'
+ alias 'awk=busybox awk'
+ alias 'cat=busybox cat'
+ alias 'clear=busybox clear'
+ alias 'cp=busybox cp'
+ alias 'cpio=busybox cpio'
+ alias 'cut=busybox cut'
+ alias 'date=busybox date'
+ alias 'dc=busybox dc'
+ alias 'df=busybox df'
+ alias 'du=busybox du'
+ alias 'depmod=busybox depmod'
+ alias 'expr=busybox expr'
+ alias 'fdisk=busybox fdisk'
+ alias 'fold=busybox fold'
+ alias 'grep=busybox grep'
+ alias 'gunzip=busybox gunzip'
+ alias 'hostname=busybox hostname'
+ alias 'kill=busybox kill'
+ alias 'killall=busybox killall'
+ alias 'less=busybox less'
+ alias 'ls=busybox ls'
+ alias 'md5sum=busybox md5sum'
+ alias 'ps=busybox ps'
+ alias 'sed=busybox sed'
+ alias 'sort=busybox sort'
+ alias 'swapoff=busybox swapoff'
+ alias 'swapon=busybox swapon'
+ alias 'sync=busybox sync'
+ alias 'tar=busybox tar'
+ alias 'timeout=busybox timeout'
+ alias 'wc=busybox wc'
+ alias 'wget=busybox wget'
+ alias 'mount=busybox.suid mount'
+ alias 'umount=busybox.suid umount'
+ VERSION='Version 0.3 Nov 25, 2024'
+ MMINoverride=
+ '[' -e /usr/local/bin/awk ]
+ TCEDIR=/etc/sysconfig/tcedir
+ DB=provides.db
+ LIST=/etc/sysconfig/tcedir/provides.db
+ Exact=0
+ NZ=1
+ FullPaths=0
+ MMIN=+15
+ TARGET=
+ TARGET=bin/go
+ SanitizeTarget
+ TARGET=bin/go
+ TARGET='bin\/go'
+ TARGET='bin\/go'
+ TARGET='bin\/go'
+ TARGET='bin\/go'
+ TARGET='bin\/go'
+ TARGET='bin\/go'
+ TARGET='bin\/go'
+ TARGET='bin\/go'
+ continue
+ StripTarget -nz
+ local '__SW=-nz'
+ TARGET='bin\/go'
+ TARGET='bin\/go'
+ TARGET='bin\/go'
+ '[' 'bin\/go' '==' -nz ]
+ StripTarget -nz
+ local '__SW=-nz'
+ TARGET='bin\/go'
+ TARGET='bin\/go'
+ TARGET='bin\/go'
+ '[' 'bin\/go' '==' -nz ]
+ StripTarget -f
+ local '__SW=-f'
+ TARGET='bin\/go'
+ TARGET='bin\/go'
+ TARGET='bin\/go'
+ '[' 'bin\/go' '==' -f ]
+ StripTarget -f
+ local '__SW=-f'
+ TARGET='bin\/go'
+ TARGET='bin\/go'
+ TARGET='bin\/go'
+ '[' 'bin\/go' '==' -f ]
+ echo 'bin\/go'
+ TARGET='bin\/go'
+ '[' 1 -eq 1 ]
+ UpdateProvidesDB
+ IsSignedInteger
+ local '__NUM='
+ '[' 0 -lt 2 ]
+ echo
+ return
+ MMINoverride=
+ '[' -n ]
+ '[' -f /etc/sysconfig/tcedir/provides.db ]
+ find /etc/sysconfig/tcedir/provides.db -mmin +15
+ '[' -z /etc/sysconfig/tcedir/provides.db ]
+ /bin/ping -A -W 1 -c 2 8.8.8.8
+ getMirror
+ BUILD=
+ '[' -z ]
+ getBuild
+ uname -m
+ BUILD=x86_64
+ '[' -f /lib/ld-linux-x86-64.so.2 ]
+ echo x86_64
+ BUILD=x86_64
+ read MIRROR
+ MIRRORPROTO=http
+ getMajorVer
+ getFullVer
+ grep '^VERSION_ID=' /etc/os-release
+ verid='VERSION_ID=17.0'
+ echo 17.0
+ fullver=17.0
+ echo 17
+ MIRROR=http://mydomain.net/tinycorelinux/17.x/x86_64/tcz
+ '[' http '!=' http ]
+ '[' http '==' https ]
+ '[' http '==' http ]
+ which zsync
+ '[' -n /usr/bin/zsync ]
+ USEZSYNC=yes
+ cd /etc/sysconfig/tcedir
+ '[' -n yes ]
+ zsync -i /etc/sysconfig/tcedir/provides.db http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db.zsync
#################### 100.0% 0.0 kBps DONE
reading seed file /etc/sysconfig/tcedir/provides.db: ***************************Read /etc/sysconfig/tcedir/provides.db. Target 98.1% complete.
Read provides.db. Target 98.1% complete. ******************
Read provides.db.part. Target 98.1% complete. ******************
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db:
###################- 98.1%^C
It seems zsync gets stuck in a loop at 98.1%. Server log shows it serving provides.db over and over again. Does the above suggest anything to you? I'm kind of stuck because I know next to nothing about zsync.
-
By using curl I can confirm that provides.db.gz is present on my server and that the server can handle partial content (note the 206 http response):
$ curl -v --range 0-1000 http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db.gz
* Trying 76.117.245.38:80...
* Connected to mydomain.net (76.117.245.38) port 80
> GET /tinycorelinux/17.x/x86_64/tcz/provides.db.gz HTTP/1.1
> Host: mydomain.net
> Range: bytes=0-1000
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/1.1 206 Partial Content
< Accept-Ranges: bytes
< Content-Length: 1001
< Content-Range: bytes 0-1000/3253446
< Content-Type: application/x-gzip
< Last-Modified: Tue, 19 May 2026 08:15:43 GMT
< Date: Wed, 20 May 2026 15:06:27 GMT
<
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
* Failure writing output to destination
* Closing connection
-
I tried running lighttpd as well as busybox httpd on my server rather than my homebrewed go-httpd . I was happy to discover that this problem (provides.sh hanging at the zsync step when provides.db is due for a refresh) occurs regardless of which httpd software I use.
So I think the problem is likely one of two things:
1. One or more files in my local mirror relevant to provides.db is/are missing/defective/misplaced
or
2. A minimalistic http server needs some extra configuration in order to successfully deal with a zsync client
Two quick questions:
1. On the official repo, are all files related to provides.db located in the tinycorelinux/[TCLversion]/[architecture]/tcz directory?
2. Is there any special configuration being used on official TCL repo's http server related to zsync?
-
If I run nginx on the server, problem goes away. This eliminates hypothesis #1 in my previous post.
Problem must have something to do with this:
- A minimalistic http server needs some extra configuration in order to successfully deal with a zsync client
Maybe this has something to do with MIME types?
-
Hi GNUser
... 1. On the official repo, are all files related to provides.db located in the tinycorelinux/[TCLversion]/[architecture]/tcz directory?
Yes they are. And their sizes match your local repo.
-
Hi GNUser
Running busybox and GNU zsync at the command line against provides.db:
tc@E310:~/Scripting/Provides$ /usr/bin/zsync -i "provides.db" "http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db.zsync"
#################### 100.0% 0.0 kBps DONE
Read provides.db. Target 100.0% complete. *****************
verifying download...checksum matches OK
used 33488896 local, fetched 0
tc@E310:~/Scripting/Provides$ /usr/local/bin/zsync -i "provides.db" "http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db.zsync"
#################### 100.0% 0.0 kBps DONE
Read provides.db. Target 100.0% complete. *****************
verifying download...checksum matches OK
used 33488896 local, fetched 0
tc@E310:~/Scripting/Provides$
Running busybox and GNU zsync at the command line against provides.db.gz:
tc@E310:~/Scripting/Provides$ /usr/bin/zsync -i "provides.db.gz" "http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db.zsync"
#################### 100.0% 0.0 kBps DONE
Read provides.db.gz. Target 100.0% complete. *******************
verifying download...checksum matches OK
used 33488896 local, fetched 0
tc@E310:~/Scripting/Provides$ /usr/local/bin/zsync -i "provides.db.gz" "http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db.zsync"
#################### 100.0% 0.0 kBps DONE
Read provides.db.gz. Target 100.0% complete. *******************
verifying download...checksum matches OK
used 33488896 local, fetched 0
tc@E310:~/Scripting/Provides$
When I copied my TC10 provides.db in place of yours, this happened:
tc@E310:~/Scripting/Provides$ cp /etc/sysconfig/tcedir/provides.db .
cp: overwrite './provides.db'? y
tc@E310:~/Scripting/Provides$ /usr/bin/zsync -i "provides.db" "http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db.zsync"
#################### 100.0% 0.0 kBps DONE
Read provides.db. Target 8.3% complete. *****
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db.gz:
#------------------- 8.3% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db.gz:
#------------------- 8.3% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db.gz:
#------------------- 8.3% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db.gz:
#------------------- 8.3% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db.gz:
#------------------- 8.3% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db.gz:
#------------------- 8.3% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db.gz:
#------------------- 8.3% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db.gz:
#------------------- 8.3% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db.gz:
#------------------- 8.3% 0.0 kBps
downloading from http://mydomain.net/tinycorelinux/17.x/x86_64/tcz/provides.db.gz:^CI had to Ctrl-C to stop it.
-
Hi Rich. Interesting results. Does this suggest a solution to you?
I'm going to try using GNU zsync to see what happens.
EDIT: No luck with GNU zsync. If it's not nginx running on the server, zsync client enters an infinite loop. How frustrating. This is the only problem I've encountered since switching from nginx to something more lightweight.
-
Hi GNUser
When I tried running the script on my TC10 system against your repo, the
CPU usage shot up and the script never exited (endless loop).
When I ran zsync from the command line against the provides.db
that I downloaded from your repo, it was happy.
When I ran zsync from the command line against the provides.db
from my TC10 system, it entered an endless loop of partial downloads.
My conclusion is, the provides.db you are checking does not match
the provides.db.zsync file.
Make sure your /etc/sysconfig/tcedir/provides.db is the same as your repo copy.
Make sure the provides.db.zsync you are referencing is coming from your repo, and
not someplace else.
... This is the only problem I've encountered since switching from nginx to something more lightweight.
Maybe a stray leftover config file or setting causing mischief?
-
Make sure your /etc/sysconfig/tcedir/provides.db is the same as your repo copy.
Isn't it zsync's job to check that--and update client's provides.db if it doesn't match repo copy? It sounds like the only time things are working well in your tests is when zsync has nothing to update because your provides.db is already current.
Make sure the provides.db.zsync you are referencing is coming from your repo, and
not someplace else.
/opt/tcemirror contains one line, which is the correct url for my repo. Shouldn't that be sufficient to ensure that the zsync command in provides.sh is grabbing the correct provides.db.zsync?
P.S. The most perplexing thing of all is that if local mirror is served by nginx on the server (vs. a more minimalistic httpd), all problems go away without changing any files in the local mirror and without changing any files on my laptop/zsync client.
-
Hi GNUser
Make sure your /etc/sysconfig/tcedir/provides.db is the same as your repo copy.
Isn't it zsync's job to check that--and update client's provides.db if it doesn't match repo copy? ...
My knowledge of how zsync works ranges from slim to none.
When running an update on the repo, this message does show up:
No URL given, so I am including a relative URL in the .zsync file - you must keep the file being served and the .zsync in the same public directory.
That seems to suggest there is no mechanism to check if the zsync file matches
the file being checked.
... Make sure the provides.db.zsync you are referencing is coming from your repo, and
not someplace else.
/opt/tcemirror contains one line, which is the correct url for my repo. Shouldn't that be sufficient to ensure that the zsync command in provides.sh is grabbing the correct provides.db.zsync?
It should. But since I can't see your setup, so it was something to check.
-
My knowledge of how zsync works ranges from slim to none.
Haha, so it's a "blind leading the blind" situation ;D
zsync is like rsync, but for a single file. It downloads just a delta to bring a local file up to date with a remote file. I've just told you 100% of what I know about zsync.
I think the point of using zsync with provides.db is to avoid re-downloading the entire provides.db file, which for TCL standards is large (at around 30 MB).
This problem is not a big deal. I don't think it's important enough for me to go back to nginx or continue troubleshooting (I'm not optimistic about finding a solution).
I'll resort to a workaround: I'm going to use a modified version of provides.sh that simply re-downloads the entire provides.db when provides.db is deemed to be too old.
-
I thought about this some more. Using zsync (which seems to only work with some http servers) and using wget (which redownloads the entire file) are not the only options.
rsync, by default, only downloads the changed parts of files. So my workaround is to use rsync instead of zsync. (rsync can work with a single file--rather than a directory--as source. But rsync does expect the destination argument to be a directory.)
This is what I did to my custom provides.sh's UpdateProvidesDB function:
# zsync seems to work only with nginx, so I'm going to use rsync instead of zsync. Let's comment-out the zsync part:
# if zsync -i "$LIST" -q "$MIRROR"/"$DB".zsync
# then
# rm -f "$DB".zs-old
# else
# if [ ! -f "$LIST" ]
# then
# wget -O "$LIST".gz "$MIRROR"/"$DB".gz
# gunzip "$LIST".gz
# fi
# fi
version=$(version)
version=${version%.*}.x
rsync -vz --progress mydomain.net:/path/to/tinycorelinux/$version/$(uname -m)/tcz/provides.db /etc/sysconfig/tcedir
-
Hi GNUser
My knowledge of how zsync works ranges from slim to none.
Haha, so it's a "blind leading the blind" situation ;D ...
Sounds about right. ::)
This provides some interesting information:
https://zsync.moria.org.uk/server
The section labeled Distribution provides some information on
server requirements that may be related to your issue.
-
This provides some interesting information:
https://zsync.moria.org.uk/server
The section labeled Distribution provides some information on
server requirements that may be related to your issue.
Hi Rich. Thank you for this. The only item that seems to be required in the server is this one: "must support HTTP Range: requests"
I can confirm that my go-httpd supports HTTP Range requests. Note the 206 status code:
Thu 5/21/26 12:23AM,/tinycorelinux/17.x/x86_64/tcz/provides.db.gz,206,192.168.10.61
I have no hot leads at the moment, but am happy with my workaround, which is to swap out zsync in favor of rsync in provides.sh.
-
Hi GNUser
Actually, it was this statement that caught my eye:
Currently it must not use Transfer-Encoding: chunked (yes, I know that makes zsync non-compliant).
I thought maybe one of the simpler servers night be violating that requirement.
-
Hi Rich. I will investigate that. Thank you.
-
Hi GNUser
Actually, it was this statement that caught my eye:
Currently it must not use Transfer-Encoding: chunked (yes, I know that makes zsync non-compliant).
I thought maybe one of the simpler servers night be violating that requirement.
for the perpetually curious
"Understanding HTTP’s Transfer-Encoding: chunked" @ https://gist.github.com/nepsilon/3c5e2c1c5c2fece59a809217a66b8ea3
the body has each of its chunks separated with X\r\n, where X is the size of the chunk in hexadecimal.
-
Maybe this has something to do with MIME types?
Yes, the problem did end up having to do with MIME types.
If I change this in my go-httpd server's source code:
http.ServeFile(w, r, path)
to this:
if strings.HasSuffix(path, ".db") || strings.HasSuffix(path, ".gz") || strings.HasSuffix(path, ".tcz") {
w.Header().Set("Content-Type", "application/octet-stream")
}
http.ServeFile(w, r, path)
...then all zsync-related problems go away.
Thread is solved.
-
Hi GNUser
So marked.
-
I spoke too soon--problem happened again, so my "fix" in Reply #17 is no good :-\
It seems this is a meta-bug that happens when the zsync client talks to some http servers (e.g., lighttpd, busybox httpd, golang server using net/http in the standard library).
I'm not optimistic I'm going to find a proper fix, but I did find two workarounds:
First and simplest workaround is to delete /usr/bin/zsync from the TCL machine. This causes both provides.sh and tce-update to fallback to using wget. The disadvantage is some wasted bandwidth.
Second solution is to use zsync2 (available at https://github.com/go-deltasync/zsync2). Note that the executable is called gozsync. For our purposes, it is a drop-in replacement for /usr/bin/zsync. Put gozsync in a directory in your PATH that appears before /usr/bin, for example, /home/tc/.local/bin, then:
$ cd /home/tc/.local/bin
$ ln -s gozsync zsyncNow gozsync/zsync2 takes precedence over the base system's zsync:
$ which -a zsync
/home/tc/.local/bin/zsync
/usr/bin/zsync
I did many tests and so far it seems zsync2/gozsync has no trouble talking to non-nginx http servers.
-
I got in touch with Colin Phipps (zsync developer), who thinks my problem may be due to a bug in zsync 0.6 series. He's looking into it. I'll keep you all posted.
-
Hi GNUser
... if strings.HasSuffix(path, ".db") || strings.HasSuffix(path, ".gz") || strings.HasSuffix(path, ".tcz") {
w.Header().Set("Content-Type", "application/octet-stream")
}
http.ServeFile(w, r, path) ...
When dealing with provides.db.gz, is HasSuffix ".gz" or ".db.gz"?
-
Hi Rich.
When dealing with provides.db.gz, is HasSuffix ".gz" or ".db.gz"?
It works either way. See the specs at https://pkg.go.dev/strings#HasSuffix
Also, here is a simple program to test it, which I called test.go:
package main
import (
"fmt"
"strings"
)
func main() {
fmt.Println(strings.HasSuffix("provides.db.gz", ".gz"))
fmt.Println(strings.HasSuffix("provides.db.gz", ".db.gz"))
}
This is what happens when it is run:
$ go run test.go
true
true
Colin, the zsync developer, got back to me. He thinks this patch fixes the bug I reported: https://github.com/cph6/zsync/commit/4f044701
I'm going to test his patch tonight.
-
Hi GNUser
... It works either way. ...
Wow, I didn't see that coming.
... He thinks this patch fixes the bug I reported: https://github.com/cph6/zsync/commit/4f044701 ...
Looks promising.
-
Hi Rich and Juanito. I compiled latest git of zsync (0.6 branch), which includes the patch. Problem is fixed :)
It would be nice if we could include this fixed zsync into the base system.
Juanito, do you want me to submit zsync for x86_64? I'm guessing it's too late for TCL17 unless you are planning a 17.1 release. Or it can go into TCL18.
[Edit]: Made changes requested in reply #26. Rich
-
Yes, please submit - it can go in 17.1
-
Hi Juanito. I submitted zsync executable for x86_64 base system plus an updated zsync extension (containing zsyncmake).
Hi Rich. Can you please fix my Reply #24? I said "I'm guessing it's too late for TCL16...16.1...TCL17" but what I meant was "I'm guessing it's too late for TCL17...17.1...TCL18." Thanks.
-
Hi GNUser
... Hi Rich. Can you please fix my Reply #24? ...
Done. :)