* [Buildroot] [autobuild.buildroot.net] Build results for 2014-04-10
@ 2014-04-11 6:30 Thomas Petazzoni
2014-04-11 7:01 ` Peter Korsgaard
0 siblings, 1 reply; 12+ messages in thread
From: Thomas Petazzoni @ 2014-04-11 6:30 UTC (permalink / raw)
To: buildroot
Build statistics for 2014-04-10
===============================
success : 56
failures : 27
timeouts : 1
TOTAL : 84
Classification of failures by reason
====================================
avahi-0.6.31 | 6
lttng-tools-2.4.0 | 3
mesa3d-10.0.4 | 2
php-5.5.11 | 2
cppcms-1.0.4 | 2
zeromq-3.2.4 | 1
jack2-37976441044d69b91d61d... | 1
libcurl-7.36.0 | 1
czmq-b5730c5f8290a611fd3b92... | 1
libwebsockets-v1.22-chrome2... | 1
cairo-1.12.10 | 1
dhcpcd-6.1.0 | 1
gd-2.0.35 | 1
openpgm-5.1.118~dfsg | 1
python-2.7.6 | 1
GEN timB18-ISO88 | 1
vlc-2.1.2 | 1
lttng-libust-2.4.0 | 1
Detail of failures
===================
xtensa | GEN timB18-ISO88 | TIM | http://autobuild.buildroot.net/results/6769c2bb05713d97f96455627a7380e4dd2195bf/
arm | avahi-0.6.31 | NOK | http://autobuild.buildroot.net/results/e54a3ff5542a11197f3aa6e543350f097647cb02/
powerpc | avahi-0.6.31 | NOK | http://autobuild.buildroot.net/results/d67269598335db792c0134de76af2db3445cca62/
arm | avahi-0.6.31 | NOK | http://autobuild.buildroot.net/results/678cae8ba5deadf599ae541468aedc9e52ce0942/
sh4a | avahi-0.6.31 | NOK | http://autobuild.buildroot.net/results/e86b40a3f8b8c8f97923bd3f263984dfecb5a032/
arm | avahi-0.6.31 | NOK | http://autobuild.buildroot.net/results/33ab1c8f1af73cb73022ae2c0652bbbc82d856c4/
x86_64 | avahi-0.6.31 | NOK | http://autobuild.buildroot.net/results/71698d593b63dd7817bcd6583a4f75d9adf85e2f/
x86_64 | cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/ef6df790cd98b29b1f5df95fc923f7b8a62caa34/
powerpc | cppcms-1.0.4 | NOK | http://autobuild.buildroot.net/results/6e8a0b0d19b4b79e34e256265d6310094954b52c/
arm | cppcms-1.0.4 | NOK | http://autobuild.buildroot.net/results/d530be6e49a5f223955d14e3d2f5bd9fd23632cb/
bfin | czmq-b5730c5f8290a611fd3b92... | NOK | http://autobuild.buildroot.net/results/f6f8eee52099afbe5fea75ffdac2074b19096c3c/
nios2 | dhcpcd-6.1.0 | NOK | http://autobuild.buildroot.net/results/9b8002f99ea10cede106b2f1cf0e36eeddff017a/
arm | gd-2.0.35 | NOK | http://autobuild.buildroot.net/results/4b4272876385cc21dd06ee946d658b8f9e225d78/
arm | jack2-37976441044d69b91d61d... | NOK | http://autobuild.buildroot.net/results/2ec7893cac7dcd22518196f0e435215297363544/
powerpc | libcurl-7.36.0 | NOK | http://autobuild.buildroot.net/results/12d63e7c06547716179f40ecbb8c4f266c05201f/
bfin | libwebsockets-v1.22-chrome2... | NOK | http://autobuild.buildroot.net/results/b7f7d9218d9b3f22687e04986117db7b8585e539/
arm | lttng-libust-2.4.0 | NOK | http://autobuild.buildroot.net/results/4bcbc168cc3cd6a5813ac4842ca98f21ad3750fa/
arm | lttng-tools-2.4.0 | NOK | http://autobuild.buildroot.net/results/f6a3099f1a050060397f887fdfbf55df6ba66fdb/
arm | lttng-tools-2.4.0 | NOK | http://autobuild.buildroot.net/results/4bc0723938b50e089576ad38627038de866b2217/
arm | lttng-tools-2.4.0 | NOK | http://autobuild.buildroot.net/results/2359dd80c5b0171ddb29fc8590ef094b09bf5ccd/
arm | mesa3d-10.0.4 | NOK | http://autobuild.buildroot.net/results/ce64164d76972f82acab277afc9c95a876c6433e/
mips | mesa3d-10.0.4 | NOK | http://autobuild.buildroot.net/results/843dc89f6ac4dd3ac80a32db86e4546fa079bfd6/
powerpc | openpgm-5.1.118~dfsg | NOK | http://autobuild.buildroot.net/results/dcc68ada4d8b82b089cbe28263fb2264d8a446ab/
arc | php-5.5.11 | NOK | http://autobuild.buildroot.net/results/9480f76a1db384d27fbc2f19742fd0c39ae63297/
arm | php-5.5.11 | NOK | http://autobuild.buildroot.net/results/827d545e665672798a8fd11c2b1df8b38c98f346/
avr32 | python-2.7.6 | NOK | http://autobuild.buildroot.net/results/a4c1fba538c9576a18d5c21807ef508fdde8f328/
sh4a | vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/74d516edc26dedd5622afa3a499b4b234904090b/
arc | zeromq-3.2.4 | NOK | http://autobuild.buildroot.net/results/a098b850eb5c40cd4e9525caaa4e2107b9f4a89d/
--
http://autobuild.buildroot.net
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-04-10
2014-04-11 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-04-10 Thomas Petazzoni
@ 2014-04-11 7:01 ` Peter Korsgaard
2014-04-11 7:30 ` Thomas Petazzoni
0 siblings, 1 reply; 12+ messages in thread
From: Peter Korsgaard @ 2014-04-11 7:01 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> Build statistics for 2014-04-10
> ===============================
> success : 56
> failures : 27
> timeouts : 1
> TOTAL : 84
> arm | avahi-0.6.31 | NOK | http://autobuild.buildroot.net/results/e54a3ff5542a11197f3aa6e543350f097647cb02/
> powerpc | avahi-0.6.31 | NOK | http://autobuild.buildroot.net/results/d67269598335db792c0134de76af2db3445cca62/
> arm | avahi-0.6.31 | NOK | http://autobuild.buildroot.net/results/678cae8ba5deadf599ae541468aedc9e52ce0942/
> sh4a | avahi-0.6.31 | NOK | http://autobuild.buildroot.net/results/e86b40a3f8b8c8f97923bd3f263984dfecb5a032/
> arm | avahi-0.6.31 | NOK | http://autobuild.buildroot.net/results/33ab1c8f1af73cb73022ae2c0652bbbc82d856c4/
> x86_64 | avahi-0.6.31 | NOK | http://autobuild.buildroot.net/results/71698d593b63dd7817bcd6583a4f75d9adf85e2f/
It seems like something happened to the tarball. Thomas, can you take a
look?
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-04-10
2014-04-11 7:01 ` Peter Korsgaard
@ 2014-04-11 7:30 ` Thomas Petazzoni
2014-04-11 8:04 ` Peter Korsgaard
0 siblings, 1 reply; 12+ messages in thread
From: Thomas Petazzoni @ 2014-04-11 7:30 UTC (permalink / raw)
To: buildroot
Dear Peter Korsgaard,
On Fri, 11 Apr 2014 09:01:36 +0200, Peter Korsgaard wrote:
> > arm | avahi-0.6.31 | NOK | http://autobuild.buildroot.net/results/e54a3ff5542a11197f3aa6e543350f097647cb02/
> > powerpc | avahi-0.6.31 | NOK | http://autobuild.buildroot.net/results/d67269598335db792c0134de76af2db3445cca62/
> > arm | avahi-0.6.31 | NOK | http://autobuild.buildroot.net/results/678cae8ba5deadf599ae541468aedc9e52ce0942/
> > sh4a | avahi-0.6.31 | NOK | http://autobuild.buildroot.net/results/e86b40a3f8b8c8f97923bd3f263984dfecb5a032/
> > arm | avahi-0.6.31 | NOK | http://autobuild.buildroot.net/results/33ab1c8f1af73cb73022ae2c0652bbbc82d856c4/
> > x86_64 | avahi-0.6.31 | NOK | http://autobuild.buildroot.net/results/71698d593b63dd7817bcd6583a4f75d9adf85e2f/
>
> It seems like something happened to the tarball. Thomas, can you take a
> look?
Weird. There are three instances of the build script on this machine,
each having its own download folder. And in one of them, the tarball
was indeed wrong:
$ find . -name 'avahi-0.6.31.tar.gz' | xargs ls -l
-rw-r--r-- 1 thomas thomas 2325974 Feb 14 2012 ./1/dl/avahi-0.6.31.tar.gz
-rw-r--r-- 1 thomas thomas 1268686 Feb 14 2012 ./2/dl/avahi-0.6.31.tar.gz
-rw-r--r-- 1 thomas thomas 1268686 Feb 14 2012 ./3/dl/avahi-0.6.31.tar.gz
The last two tarballs are OK, the first one is incorrect.
They start to differ at byte 1057289, which is just over a megabyte.
$ cmp ./1/dl/avahi-0.6.31.tar.gz ./2/dl/avahi-0.6.31.tar.gz
./1/dl/avahi-0.6.31.tar.gz ./2/dl/avahi-0.6.31.tar.gz differ: byte 1057289, line 3919
And when you look at byte 1057289 in that file, what you see is the
same contents as the beginning of the file. As if the tarball had been
truncated, and then another copy of the tarball has been appended to it.
And if you actually do:
1057288 + 1268686 = 2325974
So the part of the tarball before they start to differ, plus the size
of the normal tarball, adds up to the size of the corrupted tarball. So
it really seems like the corrupted tarball ends up with a copy of the
correct tarball.
This looks weird, and I don't have a good explanation. For now, I've
removed this bogus file, and we'll see if this occurs again in the
future.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-04-10
2014-04-11 7:30 ` Thomas Petazzoni
@ 2014-04-11 8:04 ` Peter Korsgaard
2014-04-11 11:51 ` Mike Zick
0 siblings, 1 reply; 12+ messages in thread
From: Peter Korsgaard @ 2014-04-11 8:04 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
> So the part of the tarball before they start to differ, plus the size
> of the normal tarball, adds up to the size of the corrupted tarball. So
> it really seems like the corrupted tarball ends up with a copy of the
> correct tarball.
Funky!
> This looks weird, and I don't have a good explanation. For now, I've
> removed this bogus file, and we'll see if this occurs again in the
> future.
Agreed. Thanks for looking into it!
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-04-10
2014-04-11 8:04 ` Peter Korsgaard
@ 2014-04-11 11:51 ` Mike Zick
2014-04-11 12:13 ` Thomas Petazzoni
0 siblings, 1 reply; 12+ messages in thread
From: Mike Zick @ 2014-04-11 11:51 UTC (permalink / raw)
To: buildroot
On Fri, 11 Apr 2014 10:04:02 +0200
Peter Korsgaard <jacmet@uclibc.org> wrote:
> >>>>> "Thomas" == Thomas Petazzoni
> >>>>> <thomas.petazzoni@free-electrons.com> writes:
>
> Hi,
>
> > So the part of the tarball before they start to differ, plus the
> > size of the normal tarball, adds up to the size of the corrupted
> > tarball. So it really seems like the corrupted tarball ends up
> > with a copy of the correct tarball.
>
> Funky!
>
> > This looks weird, and I don't have a good explanation. For now,
> > I've removed this bogus file, and we'll see if this occurs again
> > in the future.
>
> Agreed. Thanks for looking into it!
>
That reads like wget behavior, if interrupted and without the
"continue" option.
Mike
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-04-10
2014-04-11 11:51 ` Mike Zick
@ 2014-04-11 12:13 ` Thomas Petazzoni
2014-04-11 12:39 ` Baruch Siach
0 siblings, 1 reply; 12+ messages in thread
From: Thomas Petazzoni @ 2014-04-11 12:13 UTC (permalink / raw)
To: buildroot
Dear Mike Zick,
On Fri, 11 Apr 2014 06:51:58 -0500, Mike Zick wrote:
> > > This looks weird, and I don't have a good explanation. For now,
> > > I've removed this bogus file, and we'll see if this occurs again
> > > in the future.
> >
> > Agreed. Thanks for looking into it!
> >
>
> That reads like wget behavior, if interrupted and without the
> "continue" option.
Our wget download method normally downloads to a different temporary
file, and then moves the temporary file to the final location once the
download was successful. Hum, but it doesn't remove the temporary file
*before* starting the download:
define DOWNLOAD_WGET
test -e $(DL_DIR)/$(2) || \
($(WGET) -O $(DL_DIR)/$(2).tmp '$(call qstrip,$(1))' && \
mv $(DL_DIR)/$(2).tmp $(DL_DIR)/$(2)) || \
(rm -f $(DL_DIR)/$(2).tmp ; exit 1)
endef
So if you have the following sequence:
1/ wget downloads into tarball.tar.gz.tmp
2/ wget is interrupted by Ctrl+C, the .tmp file remains
3/ the build is restarted, so wget runs again, and downloads the file
again
4/ the download is successful, and the .tmp file is renamed to the
final name
Would this sequence be possible?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-04-10
2014-04-11 12:13 ` Thomas Petazzoni
@ 2014-04-11 12:39 ` Baruch Siach
2014-04-11 12:59 ` Thomas Petazzoni
0 siblings, 1 reply; 12+ messages in thread
From: Baruch Siach @ 2014-04-11 12:39 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Fri, Apr 11, 2014 at 02:13:46PM +0200, Thomas Petazzoni wrote:
> On Fri, 11 Apr 2014 06:51:58 -0500, Mike Zick wrote:
>
> > > > This looks weird, and I don't have a good explanation. For now,
> > > > I've removed this bogus file, and we'll see if this occurs again
> > > > in the future.
> > >
> > > Agreed. Thanks for looking into it!
> > >
> >
> > That reads like wget behavior, if interrupted and without the
> > "continue" option.
>
> Our wget download method normally downloads to a different temporary
> file, and then moves the temporary file to the final location once the
> download was successful. Hum, but it doesn't remove the temporary file
> *before* starting the download:
>
> define DOWNLOAD_WGET
> test -e $(DL_DIR)/$(2) || \
> ($(WGET) -O $(DL_DIR)/$(2).tmp '$(call qstrip,$(1))' && \
> mv $(DL_DIR)/$(2).tmp $(DL_DIR)/$(2)) || \
> (rm -f $(DL_DIR)/$(2).tmp ; exit 1)
> endef
>
> So if you have the following sequence:
>
> 1/ wget downloads into tarball.tar.gz.tmp
>
> 2/ wget is interrupted by Ctrl+C, the .tmp file remains
>
> 3/ the build is restarted, so wget runs again, and downloads the file
> again
>
> 4/ the download is successful, and the .tmp file is renamed to the
> final name
>
> Would this sequence be possible?
That's apparently what happened at
http://autobuild.buildroot.net/results/d19/d1967ec1b19211d209b6f476654bb30039da94fa/build-end.log.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-04-10
2014-04-11 12:39 ` Baruch Siach
@ 2014-04-11 12:59 ` Thomas Petazzoni
2014-04-11 14:00 ` Peter Korsgaard
0 siblings, 1 reply; 12+ messages in thread
From: Thomas Petazzoni @ 2014-04-11 12:59 UTC (permalink / raw)
To: buildroot
Dear Baruch Siach,
On Fri, 11 Apr 2014 15:39:31 +0300, Baruch Siach wrote:
> > Would this sequence be possible?
>
> That's apparently what happened at
> http://autobuild.buildroot.net/results/d19/d1967ec1b19211d209b6f476654bb30039da94fa/build-end.log.
Aah, exactly! Except that the download was not interrupt by doing a
Ctrl+C, and it's actually wget which retried the download. And:
2014-04-08 04:27:12 (3.70 MB/s) - Connection closed at byte 1057288. Retrying.
The size at which the download was interrupted matches exactly my
findings.
Is it a bug in wget? Some option we forgot to pass to wget?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-04-10
2014-04-11 12:59 ` Thomas Petazzoni
@ 2014-04-11 14:00 ` Peter Korsgaard
2014-04-18 16:27 ` Arnout Vandecappelle
0 siblings, 1 reply; 12+ messages in thread
From: Peter Korsgaard @ 2014-04-11 14:00 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> Aah, exactly! Except that the download was not interrupt by doing a
> Ctrl+C, and it's actually wget which retried the download. And:
> 2014-04-08 04:27:12 (3.70 MB/s) - Connection closed at byte 1057288. Retrying.
> The size at which the download was interrupted matches exactly my
> findings.
> Is it a bug in wget? Some option we forgot to pass to wget?
Seems like a bug to me. I don't see how this could ever be valid
behaviour.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-04-10
2014-04-11 14:00 ` Peter Korsgaard
@ 2014-04-18 16:27 ` Arnout Vandecappelle
2014-04-19 12:11 ` Thomas Petazzoni
2014-04-19 14:17 ` Mike Zick
0 siblings, 2 replies; 12+ messages in thread
From: Arnout Vandecappelle @ 2014-04-18 16:27 UTC (permalink / raw)
To: buildroot
On 11/04/14 16:00, Peter Korsgaard wrote:
>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>
> > Aah, exactly! Except that the download was not interrupt by doing a
> > Ctrl+C, and it's actually wget which retried the download. And:
>
> > 2014-04-08 04:27:12 (3.70 MB/s) - Connection closed at byte 1057288. Retrying.
>
> > The size at which the download was interrupted matches exactly my
> > findings.
>
> > Is it a bug in wget? Some option we forgot to pass to wget?
>
> Seems like a bug to me. I don't see how this could ever be valid
> behaviour.
Could also be a bug in the server: if it claims to support the Range:
option, then wget will try to use it. But if the server then returns the
start of the file instead of the request offset, you'll end up with this
corrupted file.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-04-10
2014-04-18 16:27 ` Arnout Vandecappelle
@ 2014-04-19 12:11 ` Thomas Petazzoni
2014-04-19 14:17 ` Mike Zick
1 sibling, 0 replies; 12+ messages in thread
From: Thomas Petazzoni @ 2014-04-19 12:11 UTC (permalink / raw)
To: buildroot
Dear Arnout Vandecappelle,
On Fri, 18 Apr 2014 18:27:47 +0200, Arnout Vandecappelle wrote:
> > Seems like a bug to me. I don't see how this could ever be valid
> > behaviour.
>
> Could also be a bug in the server: if it claims to support the Range:
> option, then wget will try to use it. But if the server then returns the
> start of the file instead of the request offset, you'll end up with this
> corrupted file.
Ah, correct, that's also a possibility. Not sure what we can do about
it, though.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2014-04-10
2014-04-18 16:27 ` Arnout Vandecappelle
2014-04-19 12:11 ` Thomas Petazzoni
@ 2014-04-19 14:17 ` Mike Zick
1 sibling, 0 replies; 12+ messages in thread
From: Mike Zick @ 2014-04-19 14:17 UTC (permalink / raw)
To: buildroot
On Fri, 18 Apr 2014 18:27:47 +0200
Arnout Vandecappelle <arnout@mind.be> wrote:
> > > Aah, exactly! Except that the download was not interrupt by
> > > doing a Ctrl+C, and it's actually wget which retried the
> > > download. And:
> >
> > > 2014-04-08 04:27:12 (3.70 MB/s) - Connection closed at byte
> > > 1057288. Retrying.
> >
> > > The size at which the download was interrupted matches exactly my
> > > findings.
> >
> > > Is it a bug in wget? Some option we forgot to pass to wget?
> >
> > Seems like a bug to me. I don't see how this could ever be valid
> > behaviour.
>
> Could also be a bug in the server: if it claims to support the Range:
> option, then wget will try to use it. But if the server then returns
> the start of the file instead of the request offset, you'll end up
> with this corrupted file.
>
I played with this a bit to see what the possibilities might be.
I **did not** attempt to find a server that lies in its headers.
I don't see how to deal with this, without some text processing
of the wget message output.
What you see below is:
wget -S <target file>
dd just the first part of the file, to make wget think it was
only a partial download
wget -S -c <target file>
Then made the presumption that this particular server was
functioning correctly (and my network connection did not have
a drop-out in connectivity).
I also assumed there wasn't two attempts to download the same
file with wget running at the same time (such as an in-parallel
jobs error).
I.E: Just looking at what text information is available in
"normal" operation.
What looks to be most useful is the "bottom line" - that:
2014-04-19 08:52:40 (657 KB/s) - `avahi-0.6.31.tar.gz' saved [1268686/1268686]
If the file on disk is not [xxx/1268686] then there was an
un-detected error -
make a call for human intervention (i.e: an error message and stop).
The following is the terminal capture of what I tested,
perhaps it will give someone a better idea.
core2quad ~ $ wget -S http://pkgs.fedoraproject.org/repo/pkgs/avahi/avahi-0.6.31.tar.gz/2f22745b8f7368ad5a0a3fddac343f2d/avahi-0.6.31.tar.gz
--2014-04-19 08:47:22-- http://pkgs.fedoraproject.org/repo/pkgs/avahi/avahi-0.6.31.tar.gz/2f22745b8f7368ad5a0a3fddac343f2d/avahi-0.6.31.tar.gz
Resolving pkgs.fedoraproject.org... 209.132.181.4
Connecting to pkgs.fedoraproject.org|209.132.181.4|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Sat, 19 Apr 2014 13:47:14 GMT
Server: Apache/2.2.15 (Red Hat)
Last-Modified: Tue, 14 Feb 2012 22:55:18 GMT
ETag: "10599-135bce-4b8f47d25c180"
Accept-Ranges: bytes
Content-Length: 1268686
Keep-Alive: timeout=5, max=500
Connection: Keep-Alive
Content-Type: application/x-gzip
Length: 1268686 (1.2M) [application/x-gzip]
Saving to: `avahi-0.6.31.tar.gz'
100%[=============================================================================================>] 1,268,686 659K/s in 1.9s
2014-04-19 08:47:24 (659 KB/s) - `avahi-0.6.31.tar.gz' saved [1268686/1268686]
core2quad ~ $ ls -dl ava*
-rw-rw-r-- 1 mszick mszick 1268686 2012-02-14 16:55 avahi-0.6.31.tar.gz
core2quad ~ $ mv avahi-0.6.31.tar.gz avahi-0.6.31.tar.gz.org
core2quad ~ $ dd if=avahi-0.6.31.tar.gz.org of=avahi-0.6.31.tar.gz bs=4096 count=10
10+0 records in
10+0 records out
40960 bytes (41 kB) copied, 0.00015004 s, 273 MB/s
core2quad ~ $ wget -S -c http://pkgs.fedoraproject.org/repo/pkgs/avahi/avahi-0.6.31.tar.gz/2f22745b8f7368ad5a0a3fddac343f2d/avahi-0.6.31.tar.gz
--2014-04-19 08:52:38-- http://pkgs.fedoraproject.org/repo/pkgs/avahi/avahi-0.6.31.tar.gz/2f22745b8f7368ad5a0a3fddac343f2d/avahi-0.6.31.tar.gz
Resolving pkgs.fedoraproject.org... 209.132.181.4
Connecting to pkgs.fedoraproject.org|209.132.181.4|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 206 Partial Content
Date: Sat, 19 Apr 2014 13:52:30 GMT
Server: Apache/2.2.15 (Red Hat)
Last-Modified: Tue, 14 Feb 2012 22:55:18 GMT
ETag: "10599-135bce-4b8f47d25c180"
Accept-Ranges: bytes
Content-Length: 1227726
Content-Range: bytes 40960-1268685/1268686
Keep-Alive: timeout=5, max=500
Connection: Keep-Alive
Content-Type: application/x-gzip
Length: 1268686 (1.2M), 1227726 (1.2M) remaining [application/x-gzip]
Saving to: `avahi-0.6.31.tar.gz'
100%[+++==========================================================================================>] 1,268,686 657K/s in 1.8s
2014-04-19 08:52:40 (657 KB/s) - `avahi-0.6.31.tar.gz' saved [1268686/1268686]
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-04-19 14:17 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-11 6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-04-10 Thomas Petazzoni
2014-04-11 7:01 ` Peter Korsgaard
2014-04-11 7:30 ` Thomas Petazzoni
2014-04-11 8:04 ` Peter Korsgaard
2014-04-11 11:51 ` Mike Zick
2014-04-11 12:13 ` Thomas Petazzoni
2014-04-11 12:39 ` Baruch Siach
2014-04-11 12:59 ` Thomas Petazzoni
2014-04-11 14:00 ` Peter Korsgaard
2014-04-18 16:27 ` Arnout Vandecappelle
2014-04-19 12:11 ` Thomas Petazzoni
2014-04-19 14:17 ` Mike Zick
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.