* [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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox