On Thu, Sep 09, 2021 at 04:00:39PM +0200, Stefan Esser wrote:
> I have just opened PR 258387 for this issue, which occurred during testing
> of a port with invalid MASTER_SITE.
>
> The error output of "fetch -v" should be server messages, but it appears that
> th
I have just opened PR 258387 for this issue, which occurred during testing
of a port with invalid MASTER_SITE.
The error output of "fetch -v" should be server messages, but it appears that
the buffer gets overwritten with data of unknown origin (mostly NUL bytes),
e.g.:
$ fet
On Wed, 27 Jan 2021 09:40:24 +0900
KIRIYAMA Kazuhiko wrote:
> Hi all,
>
> I've been used https://www.freebsd.org/releng/index.html to know about
> latest FreeBSD updateing status for my many applications. I found that
> index.html can't fetch yesterday.
>
> Is there
On 27.01.2021 3:40, KIRIYAMA Kazuhiko wrote:
I've been used https://www.freebsd.org/releng/index.html to know about
latest FreeBSD updateing status for my many applications. I found that
index.html can't fetch yesterday.
Is there anyone to tell me how to get latest FreeBSD updateing status
Hi all,
I've been used https://www.freebsd.org/releng/index.html to know about
latest FreeBSD updateing status for my many applications. I found that
index.html can't fetch yesterday.
Is there anyone to tell me how to get latest FreeBSD updateing status
information with source file
ion upgrade detected. Running
"pkg-static install -f pkg" recommended
Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt
Authority X3
34370670592:error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify
failed:/usr/src/crypto/openssl/ssl/statem
On Mon, Oct 08, 2018 at 08:45:35PM +0200, David Marec wrote:
> Hi
>
> The FreeBSD 12 image installer that one can download at
> https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/12.0/
> doesn't not fetch txz files from a correct location.
>
> By the fact, the install
Hi
The FreeBSD 12 image installer that one can download at
https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/12.0/
doesn't not fetch txz files from a correct location.
By the fact, the installer try to fetch files from
* ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/12.0-ALPHA8
Hi!
> Hi, if there's a better place to report this then please advise
cluster...@freebsd.org or postmas...@freebsd.org -- they are informed
about it already.
> It seems the web-mail-list software for FreeBSD has failed partially (mostly?)
It's the load-balancer in front of the mailman instance
://lists.freebsd.org/pipermail/freebsd-ports/2018-August/thread.html
but clicking on most of them throws this error:
Error 503 Backend fetch failed
Backend status: Backend fetch failed
These won't even show the message list:
https://lists.freebsd.org/pipermail/freebsd-ports/2018-July/thread.html
https
Until pkg fetch and/or pkg install can ncurses-deselect the hundreds they are
about to act on rather
than a Y, N...
cat pkg-to-fetch-file | xargs -J % pkg fetch -y %
seems to fail.
I've sed'd away the : and the right awk'd away
foo-1: foo-1_1
so the port remains
foo or foo-1, [ I forget
boxes and for
convenience I
used the workstation predefinition of FreeBSD. But with that change,
all access
of ports via fetch located at ftp-sites stopped passing the filter.
Even switching to open doesn't help and this is confusing me.
The CURRENT box in question is passing its
Recently I swaitched from pf to ipfw on some CURRENT boxes and for convenience
I used the
workstation predefinition of FreeBSD. But with that change, all access of
ports via
fetch located at ftp-sites stopped passing the filter.
Even switching to open doesn't help and this is confusing me
On 2014-03-07 13:57, O. Hartmann wrote:
Recently I swaitched from pf to ipfw on some CURRENT boxes and for
convenience I used the
workstation predefinition of FreeBSD. But with that change, all access of
ports via
fetch located at ftp-sites stopped passing the filter.
Even switching
of ports
via fetch located at ftp-sites stopped passing the filter.
Even switching to open doesn't help and this is confusing me.
The CURRENT box in question is passing its traffic within a LAN through a
gateway
running also FreeBSD CURRENT, but with pf. The gateway is performing NAT
. But with that change, all
access of ports
via fetch located at ftp-sites stopped passing the filter.
Even switching to open doesn't help and this is confusing me.
The CURRENT box in question is passing its traffic within a LAN through a
gateway
running also FreeBSD CURRENT, but with pf
Hi.
i`m trying to update my FreeBSD 10 Release to Stable, but i`m not getting
to fetch on portsnap and freebsd-update
look:
# portsnap --debug fetch
Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found.
Fetching snapshot tag from your-org.portsnap.freebsd.org...
snapshot.ssl
(u_int64_t);
+/* Native function to fetch and parse the e820 map */
+static void native_parse_memmap(caddr_t, vm_paddr_t *, int *);
+
/* Default init_ops implementation. */
struct init_ops init_ops = {
.parse_preload_data = native_parse_preload_data,
.early_delay_init = i8254_init
@@ SYSINIT(cpu, SI_SUB_CPU, SI_ORDER_FIRST, cpu_startup,
NULL);
/* Preload data parse function */
static caddr_t native_parse_preload_data(u_int64_t);
+/* Native function to fetch and parse the e820 map */
+static void native_parse_memmap(caddr_t, vm_paddr_t *, int *);
+
/* Default init_ops
(u_int64_t);
+/* Native function to fetch and parse the e820 map */
+static void native_parse_memmap(caddr_t, vm_paddr_t *, int *);
+
/* Default init_ops implementation. */
struct init_ops init_ops = {
.parse_preload_data = native_parse_preload_data,
.early_delay_init
Updating several ports on CURRENT fails with a fetch error, which
expresses itself via
[math/eigen3]
Certificate verification failed for /C=US/O=DigiCert
Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV CA-1
34380876968:error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate
On 7/31/2013 3:16 AM, O. Hartmann wrote:
Updating several ports on CURRENT fails with a fetch error, which
expresses itself via
[math/eigen3]
This should be fixed now. SSL Certificate Verification has been disabled
in ports since the distinfo is already fetched securely and used to
check
On Wed, 31 Jul 2013 07:45:33 -0700
Bryan Drewery bdrew...@freebsd.org wrote:
On 7/31/2013 3:16 AM, O. Hartmann wrote:
Updating several ports on CURRENT fails with a fetch error, which
expresses itself via
[math/eigen3]
This should be fixed now. SSL Certificate Verification has
2012/9/6 O. Hartmann ohart...@zedat.fu-berlin.de:
Hello.
Creating a port, I need to fectch sources from a site whos URL is
https://xxx.xxx.xxx.
Doing so, I end up with an Authentication error. This makes the fetch
process in the port's Makefile impossible.
I tried to fetch the source tar
Hello.
Creating a port, I need to fectch sources from a site whos URL is
https://xxx.xxx.xxx.
Doing so, I end up with an Authentication error. This makes the fetch
process in the port's Makefile impossible.
I tried to fetch the source tar-ball via wget(1), but this also fails,
wget suggests
Doug Barton do...@freebsd.org wrote:
On 07/13/2012 21:21, Jan Beich wrote:
It seems recent OpenSSL update broke fetch(1) for me.
$ diff -u $SRC_BASE/crypto/openssl/apps/openssl.cnf /etc/ssl/openssl.cnf
$ fetch https://foo/bar
fetch: https://foo/bar: Authentication error
On 07/13/2012 21:21, Jan Beich wrote:
It seems recent OpenSSL update broke fetch(1) for me.
$ diff -u $SRC_BASE/crypto/openssl/apps/openssl.cnf /etc/ssl/openssl.cnf
$ fetch https://foo/bar
fetch: https://foo/bar: Authentication error
Same error as with the patch for 1.0.0d from
It seems recent OpenSSL update broke fetch(1) for me.
$ diff -u $SRC_BASE/crypto/openssl/apps/openssl.cnf /etc/ssl/openssl.cnf
$ fetch https://foo/bar
fetch: https://foo/bar: Authentication error
Same error as with the patch for 1.0.0d from a year ago and
same workaround - s
I noted the following behaviour from fetch today.. I am actually hunting
another problem so I'm just posting it here in case anyone recognises it
and knows where to fix it...
d
48885 fetchRET read 1
48885 fetchCALL gettimeofday(0x7fffcda0,0)
48885 fetchRET
2010/6/30 Dag-Erling Smørgrav d...@des.no:
Tom Evans tevans...@googlemail.com writes:
Sorry to bump this again. I've diluted this issue down to the core
points and raised as a pr - can someone take a look, see if my
solution is correct and commit if appropriate?
Sorry, fell through the
Tom Evans tevans...@googlemail.com writes:
I think this does show that the patch could be made a little better.
We only want to go through the loop one more time if we have
credentials to send, and we have credentials to send if the rv of
http_parse_authenticate is good.
I also think the
Sorry to bump this again. I've diluted this issue down to the core
points and raised as a pr - can someone take a look, see if my
solution is correct and commit if appropriate?
http://www.freebsd.org/cgi/query-pr.cgi?pr=148087
Cheers
Tom
___
Tom Evans tevans...@googlemail.com writes:
Sorry to bump this again. I've diluted this issue down to the core
points and raised as a pr - can someone take a look, see if my
solution is correct and commit if appropriate?
Sorry, fell through the cracks. Your analysis is correct, but I'm not
My company recently enabled proxy authentication for outgoing
connections, and this has stopped ports from working.
From fetch(5), I understand that I can place my proxy authentication
in plain text in the environment*, and this will allow fetch to work
correctly, and this does work:
# env
On Mon, Jun 21, 2010 at 11:04:16AM +0100, Tom Evans wrote:
My company recently enabled proxy authentication for outgoing
connections, and this has stopped ports from working.
From fetch(5), I understand that I can place my proxy authentication
in plain text in the environment
On Mon, Jun 21, 2010 at 11:10 AM, Erwin Lansing er...@freebsd.org wrote:
On Mon, Jun 21, 2010 at 11:04:16AM +0100, Tom Evans wrote:
My company recently enabled proxy authentication for outgoing
connections, and this has stopped ports from working.
From fetch(5), I understand that I can place
, and this has stopped ports from working.
From fetch(5), I understand that I can place my proxy authentication
in plain text in the environment*, and this will allow fetch to work
correctly, and this does work:
# env | grep -i proxy
ftp_proxy=http://proxy:3128/
HTTP_PROXY_AUTH=basic:*:tev
On Mon, Jun 21, 2010 at 12:07 PM, Gary Jennejohn
gljennj...@googlemail.com wrote:
Yes. When you ran fetch by hand you didn't have the -ApRr on the CL.
Could it be that the 'p' flag is causing problems?
Try running fetch by hand again with those flags and see what happens.
If it fails, try
phase 1: make checksum
crossword-0.8.3.tar.gz doesn't seem to exist in /tmp/distfiles/.
Attempting to fetch from http://www.ldc.usb.ve/~96-28234/.
[hangs for an hour until it is killed]
This file appears to be fetching from my
What on earth does this mean?
mrtg-2.9.26b.tar.gz doesn't seem to exist in /tmp/distfiles/.
Attempting to fetch from http://people.ee.ethz.ch/~oetiker/webtools/mrtg/pub/.
fetch: mrtg-2.9.26b.tar.gz: Multiple Choices
Kris
msg47036/pgp0.pgp
Description: PGP signature
Howdy,
The webserver is returning a status code of 300 for the file.
The webserver response should be including one or more locations
from which the file is available. I'd imagine that libfetch/fetch
ignores this and moves on to the next available site.
Regards,
Chris Knight
Systems
In the last episode (Nov 20), Kris Kennaway said:
What on earth does this mean?
mrtg-2.9.26b.tar.gz doesn't seem to exist in /tmp/distfiles/.
Attempting to fetch from http://people.ee.ethz.ch/~oetiker/webtools/mrtg/pub/.
fetch: mrtg-2.9.26b.tar.gz: Multiple Choices
According to RFC 2616
On Thu, Nov 21, 2002 at 12:47:22PM +1100, Chris Knight wrote:
Howdy,
The webserver is returning a status code of 300 for the file.
The webserver response should be including one or more locations
from which the file is available. I'd imagine that libfetch/fetch
ignores this and moves
Please use a more descriptive subject line, fetch(1) is not in any way
the cause of your problem.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
Please use a more descriptive subject line, fetch(1) is not in any way
the cause of your problem.
Yes, the subject could have been more informative... Hope this one is
better.
As for the problem - it still crashes very reliably. I could try
result. During next few
reboot cycles I managed to narrow the problem a little - I am getting
100% reproducible panics when running this script as root:
#!/bin/sh
export FTP_PASSIVE_MODE=no
fetch -v ftp://ftp.iDaemons.org/pub/distfiles/pkgtools-20021103-20021106.diff.bz2
So I've compiled in DDB
The attached is a quick patch for fetch(1). It adds a new option (-g)
that forces the transfer progress to be printed, even if it thinks that
stderr is not a tty or that it is not the foreground process.
This is useful for me in a program that runs make fetch in a port
directory through a pipe
Craig Rodrigues [EMAIL PROTECTED] writes:
I tracked this down further to the _fetch_writev() function
in libfetch/common.c. Try this patch:
Stupid, dumb bug. Of course it is only triggered by specific packet
lengths which just happened not to occur during testing :(
DES
--
Dag-Erling
I just did a build-install world plus new kernel
with current sources as of 3pm PST Sunday the 27th
fetch is broken:
(src)4190}fetch -vv
ftp://ftp.fokus.gmd.de/pub/unix/cdrecord/alpha//cdrtools-1.11a39.tar.gz
--- ftp.fokus.gmd.de:21
looking up ftp.fokus.gmd.de
connecting to ftp.fokus.gmd.de:21
On Sun, Oct 27, 2002 at 06:31:27PM -0800, Manfred Antar wrote:
I noticed it when doing a portupgrade cdrtools
So yes anything that uses fetch is not going to work
OK, I started tracing this down.
Here's how to get debugging versions:
cd /usr/src/lib/libfetch
make clean
make DEBUG_FLAGS=-g
On Sun, Oct 27, 2002 at 10:21:02PM -0500, Craig Rodrigues wrote:
On Sun, Oct 27, 2002 at 06:31:27PM -0800, Manfred Antar wrote:
I noticed it when doing a portupgrade cdrtools
So yes anything that uses fetch is not going to work
OK, I started tracing this down.
Here's how to get
At 10:38 PM 10/27/2002 -0500, Craig Rodrigues wrote:
On Sun, Oct 27, 2002 at 10:21:02PM -0500, Craig Rodrigues wrote:
On Sun, Oct 27, 2002 at 06:31:27PM -0800, Manfred Antar wrote:
I noticed it when doing a portupgrade cdrtools
So yes anything that uses fetch is not going to work
OK, I
On Sun, Oct 27, 2002 at 10:38:36PM -0500, Craig Rodrigues wrote:
On Sun, Oct 27, 2002 at 10:21:02PM -0500, Craig Rodrigues wrote:
On Sun, Oct 27, 2002 at 06:31:27PM -0800, Manfred Antar wrote:
I noticed it when doing a portupgrade cdrtools
So yes anything that uses fetch is not going
Hello,
i'm using libfetch.
I want to get a file in passive mode in my local disk.
If I read trace from the remote machine, the transfert is okay
but i can't find my new imported file in the local disk.
Can you help me to find it ? :o{
Please answer me directly, i'm not a subscriber of this
* [EMAIL PROTECTED] [EMAIL PROTECTED] [001115 03:39] wrote:
Hello,
i'm using libfetch.
I want to get a file in passive mode in my local disk.
If I read trace from the remote machine, the transfert is okay
but i can't find my new imported file in the local disk.
Can you help me to find
On Thu, 26 Oct 2000, Andrea Campi wrote:
When trying to install ports, very often I find everything freezes just
after fetch completes. If I hit ^C and type "make install" again, the
tarball is there, that's why I say that fetch is already done.
If I hit ^T, I see fetch sitting
just
after fetch completes. If I hit ^C and type "make install" again, the
tarball is there, that's why I say that fetch is already done.
If I hit ^T, I see fetch sitting in sbwait, the time not increasing.
Just a note, I got the same thing under 4-STABLE with the latest
sources.
When trying to install ports, very often I find everything freezes just
after fetch completes. If I hit ^C and type "make install" again, the
tarball is there, that's why I say that fetch is already done.
If I hit ^T, I see fetch sitting in sbwait, the time not increasing.
Any idea?
Sorry to follow up on myself... I forgot to mention this is -CURRENT,
updated to a couple of days ago...
-Original Message-
From: Andrea Campi
Sent: Thursday, October 26, 2000 6:44 PM
To: '[EMAIL PROTECTED]'
Subject: Problem in fetch
When trying to install ports, very often I
[Making sure Dag-Erling gets the mail]
-On [20001026 18:45], Andrea Campi ([EMAIL PROTECTED]) wrote:
When trying to install ports, very often I find everything freezes just
after fetch completes. If I hit ^C and type "make install" again, the
tarball is there, that's why I say
Hi there,
My fbsd box is (ADSL) connected to the net through dynamic IPs,
so no mails are able to send in, they go to the account offered
by my ISP. i need to check mail manually a period of time.
Is there any package that can be used to fetch mails back to
my fbsd box in every 10
My fbsd box is (ADSL) connected to the net through dynamic IPs,
so no mails are able to send in, they go to the account offered
by my ISP. i need to check mail manually a period of time.
Is there any package that can be used to fetch mails back to
my fbsd box in every 10 or 20 min
in, they go to the account offered
by my ISP. i need to check mail manually a period of time.
Is there any package that can be used to fetch mails back to
my fbsd box in every 10 or 20 min. automatically?
--
// Donny
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubs
Blaz Zupan wrote:
Yes, check out fetchmail:
http://www.freebsd.org/cgi/ports.cgi?query=fetchmailstype=all
But in the future please send such questions to the freebsd-questions mailing
list, not to freebsd-current.
Thanks to all replies, and sorry too. I figure i do put the
question
on it at the
application level.
I'm not relying on it - fetch(1) has always had the ability to specify
passwords in environment variables. I'm just saying it's less of a
problem than it was before.
On a related note, I just suddenly remembered about .netrc. Libfetch
ought to be able to read FTP logins and passwords from
Poul-Henning Kamp [EMAIL PROTECTED] writes:
What happened to the FTP_PASSIVE_MODE environment variable ? As
far as I can tell it is no longer supported and as a result sysinstall
is broken. It uses Active FTP even if you select Passive FTP on
the menu :-(
Sysinstall does not use libfetch.
other users' processes'
environment, I don't think it's a very big issue anymore.
POLA says you should not have changed what fetch(1) expects from the
environmental var.
Has this feature been deliberately left out, or is it just one of the
bits that you haven't gotten around to implementing
In message [EMAIL PROTECTED] Poul-Henning Kamp writes:
: What happened to the FTP_PASSIVE_MODE environment variable ? As
: far as I can tell it is no longer supported and as a result sysinstall
: is broken. It uses Active FTP even if you select Passive FTP on
: the menu :-(
I've also noticed
Peter Jeremy [EMAIL PROTECTED] writes:
Whilst the environment is somewhat safer than the command line, I'd
still prefer not to have passwords embedded in environment variables.
Since ps(1) no longer allows users to view other users' processes'
environment, I don't think it's a very big issue
On 3 Aug 2000, Dag-Erling Smorgrav wrote:
Peter Jeremy [EMAIL PROTECTED] writes:
Whilst the environment is somewhat safer than the command line, I'd
still prefer not to have passwords embedded in environment variables.
Since ps(1) no longer allows users to view other users' processes'
I don't recall seeing this mentioned: In order to access the Internet,
I need to use proxy authorization. With the old fetch(1) I could use
an environment variable like "HTTP_PROXY_AUTH=basic:*:username" and
it would prompt for a password.
The new libfetch-based fetch(
I am using fwtk-2.1 on a firewall, and with the latest builds, fetch
seems to have changed behaviors such that it no longer works with it.
I have FTP_PROXY set to "red:9696"
the difference in behavior seems that older versions of fetch would
send a USER command like this:
USER [EMAIL
Hi, I found a weird problem with your new fetch(1).
Please try fetching the following file with both fetch and wget for
comparison:
http://www.hiei.kit.ac.jp/~hitomi/mutt/mutt/manual_ja-1.2i-0.tar.gz
1) Fetching the file with wget
knu@archon[2]% uname
Sorry, I seem to have supplied a wrong URL. Here's the correct one.
http://www.hiei.kit.ac.jp/~hitomi/mutt/manual_ja-1.2i-0.tar.gz
--
/
/__ __
/ ) ) ) ) /
Akinori -Aki- MUSHA aka / (_ / ( (__( @
At 17 Jul 2000 23:38:23 +0200,
DES wrote:
I've spent most of the night fixing this and am about to commit the
last changes, so you should be able to cvsup and build working
libfetch and fetch in an hour or two.
Thanks! I could confirm that your changes fixed the problem, and am
happy to see
Also sprach Andreas Klemm ([EMAIL PROTECTED]):
I'm using -current of yesterday and tcsh.
When installing a FreeBSD port and I interrupt a "make all install clean"
session, when make is in the "make fetch target", the fetch process isn't
killed and continues to run alon
Since my last buildworld, fetch no longer works properly:
$ fetch http://www.bom.gov.au/cgi-bin/wrap_fwo.pl?IDS10034.txt
Receiving wrap_fwo.pl?IDS10034.txt
-1 bytes transferred in 0.7 seconds (-1.47 Bps)
It would be nice to have an error message here, not to mention a more
accurate bottom
Greg Lehey [EMAIL PROTECTED] writes:
Since my last buildworld, fetch no longer works properly:
$ fetch http://www.bom.gov.au/cgi-bin/wrap_fwo.pl?IDS10034.txt
Receiving wrap_fwo.pl?IDS10034.txt
-1 bytes transferred in 0.7 seconds (-1.47 Bps)
Looks like stale sources. The -1 bug
On Friday, 14 July 2000 at 10:53:42 +0200, Dag-Erling Smorgrav wrote:
Greg Lehey [EMAIL PROTECTED] writes:
Since my last buildworld, fetch no longer works properly:
$ fetch http://www.bom.gov.au/cgi-bin/wrap_fwo.pl?IDS10034.txt
Receiving wrap_fwo.pl?IDS10034.txt
-1 bytes transferred
and fetch and try again. If you're still having
trouble, rebuild libfetch with debugging enabled, run fetch -vvv and
mail me the output.
# cd /usr/src
# cvs update -A lib/libfetch usr.bin/fetch
# cd lib/libfetch
# make clean make depend make -DDEBUG make install
# cd ../../usr.bin/fetch
# make
At 12 Jul 2000 08:56:11 GMT,
Dag-Erling Smorgrav [EMAIL PROTECTED] wrote:
The bug is only in the status report, check the acutal size of
fetch.out. I fixed this in a commit half an hour ago.
Thanks!
By the way, current implementation of fetch(1) ignores "301 redirect"
Jun Kuriyama [EMAIL PROTECTED] writes:
By the way, current implementation of fetch(1) ignores "301 redirect"
silently. Is it expected behavior? Should it make warning message
without -v option? (or following redirection?)
Uh, that's a bug. It's supposed to work. I'll be right o
Jun Kuriyama [EMAIL PROTECTED] writes:
By the way, current implementation of fetch(1) ignores "301 redirect"
silently. Is it expected behavior? Should it make warning message
without -v option? (or following redirection?)
The bug is twofold: first, it doesn't handle relative
My current box (make world'ed this morning) fails on fetch(1) for some
CGI scripts.
% fetch -v -v http://www.FreeBSD.org/cgi/search.cgi/
looking up www.FreeBSD.org
connecting to www.FreeBSD.org:80
requesting http://www.FreeBSD.org:80/cgi/search.cgi/
looking up www.FreeBSD.org
connecting
Jun Kuriyama [EMAIL PROTECTED] writes:
My current box (make world'ed this morning) fails on fetch(1) for some
CGI scripts.
The bug is only in the status report, check the acutal size of
fetch.out. I fixed this in a commit half an hour ago.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED
Dag-Erling Smorgrav [EMAIL PROTECTED] wrote:
It seems that fetch(1) can not fetch any file. In this case, the
downloaded(?) file size is zero.
DES Make sure you have revision 1.2 (or newer) of src/usr.bin/fetch/fetch.c:
I cvsupped 20 minutes ago and remade libfetch and fetch. It works
On 05 Jul 2000 12:46:11 +0900, NAKAJI Hiroyuki wrote:
The problem is that the report of '/usr/bin/fetch' is strange. For
example,
$ fetch http://www.samba.gr.jp/project/samba-ja/index.html.en
Receiving index.html.en
-1 bytes transferred in 0.4 seconds (-2.28 Bps)
Please be sure
(but building it anyway)
===Verifying install for bzip2 in /usr/ports/archivers/bzip2
bzip2-1.0.1.tar.gz doesn't seem to exist on this system.
Attempting to fetch from ftp://ftp.tutrp.tut.ac.jp/pub/FreeBSD/ports/distfiles/.
fetch: warning: the -b option is deprecated
fetch: bzip2-1.0.1
I made world yesterday.
$ uname -a
FreeBSD nakaji.tutrp.tut.ac.jp 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Tue
Jul 4 12:15:52 JST 2000
[EMAIL PROTECTED]:/home2/obj/usr/src/sys/NAKAJI i386
The problem is that the report of '/usr/bin/fetch' is strange. For
example,
$ fetch http://www.samba.gr.jp
Garrett Wollman [EMAIL PROTECTED] writes:
On 30 Jun 2000 12:35:28 +0200, Dag-Erling Smorgrav [EMAIL PROTECTED] said:
You're not one for constructive criticism, are you? I don't know how
What part of YOU MAY NOT CLAIM COPYRIGHT ON MY TEXT don't you
understand?
That's a technicality, and I'll
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
Garrett Wollman [EMAIL PROTECTED] writes:
On 30 Jun 2000 12:35:28 +0200, Dag-Erling Smorgrav [EMAIL PROTECTED] said:
You're not one for constructive criticism, are you? I don't know how
What part of YOU MAY NOT CLAIM COPYRIGHT ON MY TEXT don't
The new fetch does not show progress when dl'ing stuff for ports.
I tried adding FETCH_BEFORE_ARGS = " -v " in /usr/ports/Mk/bsd.ports.mk
but then fetch just dies:
fetch: -v : parse error
Segmentation fault - core dumped
Leif
To Unsubscribe: send mail to [EMAIL PROTECTED]
with &q
Garrett Wollman [EMAIL PROTECTED] writes:
On 29 Jun 2000 09:58:20 +0200, Dag-Erling Smorgrav [EMAIL PROTECTED] said:
I've replaced fetch(1) with a libfetch-based implementation.
It introduces numerous style bugs in both code and documentation, and
furthermore claims copyright on text
On 30 Jun 2000 12:35:28 +0200, Dag-Erling Smorgrav [EMAIL PROTECTED] said:
You're not one for constructive criticism, are you? I don't know how
What part of YOU MAY NOT CLAIM COPYRIGHT ON MY TEXT don't you
understand?
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
On 29 Jun 2000 09:58:20 +0200, Dag-Erling Smorgrav [EMAIL PROTECTED] said:
I've replaced fetch(1) with a libfetch-based implementation.
It introduces numerous style bugs in both code and documentation, and
furthermore claims copyright on text in the manual page which I
wrote. It also removes
Christian Weisgerber [EMAIL PROTECTED] wrote:
The following, completely innocuous command line
$ fetch -o - http://sites.inka.de/mips/unix/freebsd/xterm.shar | sh
executed as a non-priviledged user, reproducibly panics the machine.
It's caused by fdesc mounted on /dev/fd.
I sent in a PR
Christian Weisgerber [EMAIL PROTECTED] wrote:
The following, completely innocuous command line
$ fetch -o - http://sites.inka.de/mips/unix/freebsd/xterm.shar | sh
executed as a non-priviledged user, reproducibly panics the machine.
Some people have mailed that this particular command line
5.0-CURRENT from ~May 17, dual ppro.
The following, completely innocuous command line
$ fetch -o - http://sites.inka.de/mips/unix/freebsd/xterm.shar | sh
executed as a non-priviledged user, reproducibly panics the machine.
-
#0 boot (howto=256) at ../../kern/kern_shutdown.c
: Christian Weisgerber [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: "fetch | sh" panics system
5.0-CURRENT from ~May 17, dual ppro.
The following, completely innocuous command line
$ fetch -o - http://sites.inka.de/mips/unix/freebsd/xterm.shar | sh
executed as a non-privil
On Tue 2000-05-30 (16:28), Christian Weisgerber wrote:
5.0-CURRENT from ~May 17, dual ppro.
The following, completely innocuous command line
$ fetch -o - http://sites.inka.de/mips/unix/freebsd/xterm.shar | sh
(nbm@monster) /home/nbm uname -a
FreeBSD monster.sunesi.com 5.0-CURRENT FreeBSD
1 - 100 of 107 matches
Mail list logo
