Den 12 maj 2015 07:47 skrev :
>
> Thanks Jens! I can add you to the bitbucket if you wish so you can
> contribute at your leisure. Also, if anyone else wants commit access,
> just ask. :) (I think bitbucket has some dumb limited commit bit
> thing though. Hopefully I'll get off it soon.)
>
> --
could you be more specific what files fail to unpack with tar?
--
cinap
Both tar.gz (zlib official site) and tar.bz2 (mksh official site). I just
wonder if they get corrupted during transfer with hget or if there is a
different issue.
Den 14 maj 2015 10:49 skrev :
> could you be more specific what files fail to unpack with tar?
>
> --
> cinap
>
>
why can't you just give a url so someone can try to reproduce it?
--
cinap
i just tried this and it works all fine:
hget http://bitbucket.org/9front/plan9front/get/tip.tar.gz | gunzip | tar t
so please give a example command with a url that gives you issues.
--
cinap
On Thursday 14 May 2015 12:52:48 cinap_len...@felloff.net wrote:
> i just tried this and it works all fine:
>
> hget http://bitbucket.org/9front/plan9front/get/tip.tar.gz | gunzip | tar t
>
> so please give a example command with a url that gives you issues.
Hi
sorry about the lack of details be
On Thursday 14 May 2015 13:10:20 Jens Staal wrote:
> This might be a vbox bug (known for flaky network? I use the recommended
> settings from 9front wiki), so I will try in qemu instead.
I just tried with the archives in qemu too and got the same error (and the
same deviant md5sum) - so hget is
found it. the server sends Content-Encoding header which causes hget
to add a decompression filter, so you get as output a tarball.
<- Content-Type: application/x-gzip
<- Content-Encoding: gzip
from the w3c:
The Content-Encoding entity-header field is used as a modifier to the
media-type.
When
haha, this appears to be an apache bug, and mozilla has work arrounds
for this. we might need todo similar thing and check for content type
as well.
--
cinap
commited a work arround for this now.
--
cinap
nope, apache is wired.
--
cinap
cinap_len...@felloff.net wrote:
|found it. the server sends Content-Encoding header which causes hget
|to add a decompression filter, so you get as output a tarball.
|
|<- Content-Type: application/x-gzip
|<- Content-Encoding: gzip
|
|this is clearly silly, as the file is already compresse
pretty sure this is apache bug/misconfiguration. googled for it
and the issue seems to be known problem.
--
cinap
Does anyone have a 3d model of Glenda?
Thanks,
Andrés
Quoting Andrés Domínguez :
Does anyone have a 3d model of Glenda?
http://glenda.cat-v.org/gallery/stuffed-glenda.jpg
That's adorable!
On May 14, 2015 11:57:31 AM CDT, Kurt H Maier wrote:
>Quoting Andrés Domínguez :
>
>> Does anyone have a 3d model of Glenda?
>
>http://glenda.cat-v.org/gallery/stuffed-glenda.jpg
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
I want one!
--
Paul Ivanov
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
On Thursday 14 May 2015 16:37:05 cinap_len...@felloff.net wrote:
> pretty sure this is apache bug/misconfiguration. googled for it
> and the issue seems to be known problem.
The zlib archive works fine now :)
by the way, did you try the mksh archive after hget was fixed? I still get the
same erro
I tried out the sbase zip on my system. That seems to work fine. Heres the log:
cpu% lc
sbase-master.zip
cpu% unzip -f sbase-master.zip
cpu% lc
sbase-master/ sbase-master.zip
cpu% cd sbase-master/
cpu% lc
LICENSE comm.1 find.1 md5.h readlink.c
sp
the sbase works fine for me, tho i can reproduce the mksh-R50f.tgz gzip
problem.
lemme do some debugging on that.
--
cinap
fixed, its a bug in gunzip. the extra-len field in the gzip header has two
byte length field instead of one byte.
commited the fix.
--
cinap
21 matches
Mail list logo
