| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
portsnap.
Discussed with: alfred
Reviewed by: cperciva
|
| |
|
| |
|
|
|
|
|
| |
Use a percent style indicator instead of emitting one
long line of patch numbers.
|
|
|
|
|
|
|
|
|
|
|
| |
errors later on.
PR: bin/172715
Submitted by: Matthew D.Fuller <fullermd@over-yonder.net> (older
version)
Submitted by: dteske
Approved by: cperciva
MFC after: 1 week
|
| |
|
|
|
|
|
| |
Spotted by: Ruslan Mahmatkhanov
Approved by: gabor (mentor, implicit)
|
|
|
|
|
|
|
| |
PR: docs/171759
Submitted by: Paul Hoffman (phoffman at proper dot com)
Approved by: cperciva, gabor (mentor)
MFC after: 3 days
|
|
|
|
|
|
|
|
| |
a terminal.
Submitted by: Hannes h2+fbsdports@fsfe.org
Approved by: cperciva
MFC after: 1 week
|
|
|
|
|
|
|
|
| |
for update.
PR: bin/152856
Approved by: cperciva
MFC after: 3 days
|
|
|
|
| |
Pointed out by: gcooper
|
|
|
|
|
|
|
|
| |
handle splitting input files on a '|'. This greatly
reduces the time taken to process several databases
during the update process.
Additionally add some more debug logging.
|
|
|
|
|
|
|
| |
Also add some quotes around command substitution where useful and possible.
Reviewed by: cperciva
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is done to speed up extraction significantly (both for portsnap
extract and update) in the case of slow NSS modules (like nss_ldap) as
it avoids having to look up uid and gid for root / wheel.
The reason this is a bigger problem for portsnap than for many other
system operations, is that portsnap executes tar(1) once for each port
so the internal uid/gid caching in tar(1) only helps a bit, resulting
in many user lookup calls.
Discussed with: cperciva
|
|
|
|
| |
They have no effect when coming in pairs, or before .Bl/.Bd
|
|
|
|
|
|
| |
translating these manual pages. Minor corrections by me.
Submitted by: Nobuyuki Koganemaru <n-kogane@syd.odn.ne.jp>
|
| |
|
|
|
|
|
|
|
|
| |
based on whether fd 0 is a terminal, and then runs (extract|update)
based on whether ${PORTSDIR} exists.
Requested by: alfred
MFC after: 1 month
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(1) phttpget is attempting to download enough files that it can't send
all the requests at once, and
(2) the remote server forcibly closes the connection, resulting in RST
packets being sent,
phttpget will receive a SIGPIPE and terminate without downloading all
of the files.
This is probably responsible for a number of hard-to-reproduce errors
with portsnap and freebsd-update.
MFC after: 3 days
|
|
|
|
|
|
| |
PR: docs/127401
Submitted by: Mick Charles Beaver <mick@cs.wisc.edu>
MFC after: 1 week
|
|
|
|
|
| |
Requested by: brooks
Reminded by: brooks, about halfway through his BSDCan talk
|
|
|
|
|
|
|
|
| |
comparisons for header keywords. Apparently some proxies use creative
capitalization.
Weird proxy found by: brooks
MFC after: 3 days
|
|
|
|
|
|
|
|
| |
paragraph clarifying that portsnap does not behave the same way as
cvs and cvsup where local modifications are concerned.
Submitted by: peter
Feet shot: peter, kris, obrien, + many others
|
|
|
|
|
|
|
| |
an index for FreeBSD 7.x too.
MFC After: 1 week
Approved by: re (hrs)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
be marked as HTTP/1.1 but "Connection: Keep-Alive" is added; this convinces
HTTP/1.0 servers and proxies to hold the TCP connection open despite not
being able to use HTTP pipelining.
This dramatically cuts down on the number of TCP connections (and thus port
numbers) used by portsnap when talking to an HTTP/1.0 proxy (e.g., squid),
and has the side benefit of improving performance in those cases.
Tested by: simon
Approved by: re (kensmith)
MFC After: 1 week
|
|
|
|
|
|
| |
of seconds, just like in fetch(1)).
Submitted by: rdivacky
|
|
|
|
|
|
|
| |
sorting.
PR: bin/104505
MFC after: 3 days
|
| |
|
|
|
|
| |
Pointed out by: ru
|
|
|
|
|
|
|
|
|
| |
can read two variables at once; and suffix pattern deletion) to make the
extract command fork fewer processes.
With the portsnap snapshot and the ports tree in swap-backed memory
disks on my 1.4GHz laptop, this reduces 178800 processes and 195/56/126
seconds of real/user/sys time to 44600 processes and 103/34/60 seconds.
|
|
|
|
| |
Pointed out by: ceri
|
|
|
|
| |
Requested by: brooks
|
|
|
|
|
|
|
| |
When /usr/ports/foo/bar is a symlink pointing outside the tree, this
deletes the symlink instead of the directory it points to.
Requested by: delphij
|
|
|
|
|
| |
"http_proxy", since some people apparently do this and fetch(3)
allows it.
|
|
|
|
|
| |
Pointy hat to: cperciva
Pointed out by: pjd
|
|
|
|
|
|
| |
commit.
Noticed by: simon
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
interact very nicely with HTTP proxies: Since proxies do not know
that all the files on portsnap1.freebsd.org are identical to the
files with the same names on portsnap2.freebsd.org, said proxies end
up downloading and storing files in duplicate.
This commit uses the HTTP_PROXY environment variable, if set, to
generate a random number seed for use in selecting a mirror. This
means that if several systems all have the same HTTP_PROXY value set,
they will ask the proxy to fetch files from the same mirror (unless
that mirror fails, in which case all the systems will use the same
second choice, et cetera).
Portsnap still doesn't interact very well with "transparent" HTTP
proxies, but there's nothing I can do about those.
Requested by: simon
Sponsored by: FreeBSD security development fundraiser
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
track of which mirrors we have tried and try a different mirror if we
fail when trying to download the SSL public key or the snapshot
signature.
Failures later in the download process will not result in switching to
a different mirror, for two reasons:
1. If is very unlikely that a mirror will fail partway through the
process of downloading updates.
2. If we switched from a more recently updated mirror to a less
recently updated mirror partway through the download process, we would
end up failing anyway because we would be trying to fetch files which
the second mirror didn't have yet.
PR: bin/96288
Requested by: lots of people
Sponsored by: FreeBSD security development fundraiser
|
|
|
|
|
|
|
|
|
| |
the host(1) from BIND 9. This doesn't matter for HEAD, but will help
people who install portsnap from the ports tree onto older versions of
FreeBSD.
PR: ports/93901
Sponsored by: FreeBSD security development fundraiser
|
|
|
|
|
|
|
|
| |
http://lists.freebsd.org/pipermail/freebsd-current/2006-March/061725.html
The src.conf(5) manpage is to follow in a few days.
Brought to you by: imp, jhb, kris, phk, ru (all bugs are mine)
|
|
|
|
|
|
|
|
| |
to use portsnap from behind a http proxy. Some HTTP proxy don't like
trailing dot in the servername.
Approved by: cperciva
MFC after: 2 days
|
|
|
|
|
| |
Approved by: cperciva
MFC after: 2 days
|
|
|
|
|
| |
Approved by: cognet (mentor)
MFC after: 3 days
|
| |
|
|
|
|
|
| |
Correctly identify the host and port values on a failed
getaddrinfo lookup.
|
|
|
|
|
|
|
|
|
| |
snapshot in order to avoid unnecessary re-downloading.
Remove the earlier "rm -f ${SNAPSHOTHASH}.tgz" to make this work.
Suggested by: Lars Engels
MFC after: 7 days
|
|
|
|
|
|
|
| |
3600 seconds.
Suggested by: Niki Denev
MFC after: 3 days
|
|
|
|
|
|
|
|
| |
instead of complaining that "Directory does not exist or is not
writable".
Suggested by: {tlp, siep} via IRC
MFC after: 1 week
|
|
|
|
|
|
|
| |
is trying to depend upon the non-existent port.
Suggested by: kris
MFC after: 3 days
|
|
|
|
|
|
|
|
| |
Make sure that the number of lines read is non-zero before in order to
avoid dumping core.
Reported by: Wojciech A. Koszek
Pointy hat to: cperciva
|