[Pharo-project] Unable to use Monticello in last images from Jenkins
Hi, Since a couple of weeks i'm have not been able to download packages with Metacello on last image versions from Jenkins. Today i found that if i revert changes on httpClient method from MCHttpRepository everything works fine again. I haven't research deeply on why, i'm not an expert on Zinc, but the message that is breaking everything and making my image to receive a 400 error from squeaksource is setAcceptEncodingGzip that is addinng the gzip header to the requests. As i said, i haven't going to deep with this but as i am the only one who is watching this behavior perhaps is something only for squeaksource. If this is actually an issue and not some fault from myself, and someone give me some help, i can help with the solution. Cheers, Guido.
You say you cannot download from squeaksource in the latest 2.0 image? We use that regularly, for instance for the NativeBoost build, and everything works fine (win / linux / mac) That leaves me quite puzzled about the real cause of this bug... On 2012-10-31, at 21:47, Guido Chari <charig@gmail.com> wrote:
Hi,
Since a couple of weeks i'm have not been able to download packages with Metacello on last image versions from Jenkins.
Today i found that if i revert changes on httpClient method from MCHttpRepository everything works fine again.
I haven't research deeply on why, i'm not an expert on Zinc, but the message that is breaking everything and making my image to receive a 400 error from squeaksource is setAcceptEncodingGzip that is addinng the gzip header to the requests.
As i said, i haven't going to deep with this but as i am the only one who is watching this behavior perhaps is something only for squeaksource.
If this is actually an issue and not some fault from myself, and someone give me some help, i can help with the solution.
Cheers, Guido.
Yes, since a couple of weeks i can't. I'm on a Unix now behind a transparent proxy. Same Vm, on same machine, behind the same proxy, no problem if strip out the gzip header from the packet. I'm using a custom personalized VM. But the only thing that is generating the error is the gzip header option on the http packet. Is that option deeply related or coupled to the vm? BTW, the error is a 400 from the server so i don't believe so. No one else experimenting the same as me? 2012/10/31 Camillo Bruni <camillobruni@gmail.com>
You say you cannot download from squeaksource in the latest 2.0 image?
We use that regularly, for instance for the NativeBoost build, and everything works fine (win / linux / mac)
That leaves me quite puzzled about the real cause of this bug...
On 2012-10-31, at 21:47, Guido Chari <charig@gmail.com> wrote:
Hi,
Since a couple of weeks i'm have not been able to download packages with Metacello on last image versions from Jenkins.
Today i found that if i revert changes on httpClient method from MCHttpRepository everything works fine again.
I haven't research deeply on why, i'm not an expert on Zinc, but the message that is breaking everything and making my image to receive a 400 error from squeaksource is setAcceptEncodingGzip that is addinng the gzip header to the requests.
As i said, i haven't going to deep with this but as i am the only one who is watching this behavior perhaps is something only for squeaksource.
If this is actually an issue and not some fault from myself, and someone give me some help, i can help with the solution.
Cheers, Guido.
Would it be possible to test without the transparant proxy ?
From another location, like from home ? If this would fail for everyone, we would have heard about it much sooner.
On 31 Oct 2012, at 22:27, Guido Chari <charig@gmail.com> wrote:
Yes, since a couple of weeks i can't. I'm on a Unix now behind a transparent proxy. Same Vm, on same machine, behind the same proxy, no problem if strip out the gzip header from the packet.
I'm using a custom personalized VM. But the only thing that is generating the error is the gzip header option on the http packet. Is that option deeply related or coupled to the vm? BTW, the error is a 400 from the server so i don't believe so.
No one else experimenting the same as me?
2012/10/31 Camillo Bruni <camillobruni@gmail.com> You say you cannot download from squeaksource in the latest 2.0 image?
We use that regularly, for instance for the NativeBoost build, and everything works fine (win / linux / mac)
That leaves me quite puzzled about the real cause of this bug...
On 2012-10-31, at 21:47, Guido Chari <charig@gmail.com> wrote:
Hi,
Since a couple of weeks i'm have not been able to download packages with Metacello on last image versions from Jenkins.
Today i found that if i revert changes on httpClient method from MCHttpRepository everything works fine again.
I haven't research deeply on why, i'm not an expert on Zinc, but the message that is breaking everything and making my image to receive a 400 error from squeaksource is setAcceptEncodingGzip that is addinng the gzip header to the requests.
As i said, i haven't going to deep with this but as i am the only one who is watching this behavior perhaps is something only for squeaksource.
If this is actually an issue and not some fault from myself, and someone give me some help, i can help with the solution.
Cheers, Guido.
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
could you try the following "benchmarks" http://dev.nuclearrooster.com/2009/11/08/checking-gzipdeflate-server-respons... with the following urls (just 2 projects): http://smalltalkhub.com/mc/estebanlm/Voyage/main http://squeaksource.com/NativeBoost/ both support gzip answers without problems. On 2012-10-31, at 23:47, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Would it be possible to test without the transparant proxy ? From another location, like from home ? If this would fail for everyone, we would have heard about it much sooner.
On 31 Oct 2012, at 22:27, Guido Chari <charig@gmail.com> wrote:
Yes, since a couple of weeks i can't. I'm on a Unix now behind a transparent proxy. Same Vm, on same machine, behind the same proxy, no problem if strip out the gzip header from the packet.
I'm using a custom personalized VM. But the only thing that is generating the error is the gzip header option on the http packet. Is that option deeply related or coupled to the vm? BTW, the error is a 400 from the server so i don't believe so.
No one else experimenting the same as me?
2012/10/31 Camillo Bruni <camillobruni@gmail.com> You say you cannot download from squeaksource in the latest 2.0 image?
We use that regularly, for instance for the NativeBoost build, and everything works fine (win / linux / mac)
That leaves me quite puzzled about the real cause of this bug...
On 2012-10-31, at 21:47, Guido Chari <charig@gmail.com> wrote:
Hi,
Since a couple of weeks i'm have not been able to download packages with Metacello on last image versions from Jenkins.
Today i found that if i revert changes on httpClient method from MCHttpRepository everything works fine again.
I haven't research deeply on why, i'm not an expert on Zinc, but the message that is breaking everything and making my image to receive a 400 error from squeaksource is setAcceptEncodingGzip that is addinng the gzip header to the requests.
As i said, i haven't going to deep with this but as i am the only one who is watching this behavior perhaps is something only for squeaksource.
If this is actually an issue and not some fault from myself, and someone give me some help, i can help with the solution.
Cheers, Guido.
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
Both tests succeed. I couldn't read at home so i couldn't test it without the proxy but i'm "almost sure" the proxy is not explaining the issue. 2012/11/1 Camillo Bruni <camillobruni@gmail.com>
could you try the following "benchmarks"
http://dev.nuclearrooster.com/2009/11/08/checking-gzipdeflate-server-respons...
with the following urls (just 2 projects): http://smalltalkhub.com/mc/estebanlm/Voyage/main http://squeaksource.com/NativeBoost/
both support gzip answers without problems.
On 2012-10-31, at 23:47, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Would it be possible to test without the transparant proxy ? From another location, like from home ? If this would fail for everyone, we would have heard about it much sooner.
On 31 Oct 2012, at 22:27, Guido Chari <charig@gmail.com> wrote:
Yes, since a couple of weeks i can't. I'm on a Unix now behind a transparent proxy. Same Vm, on same machine, behind the same proxy, no problem if strip out the gzip header from the packet.
I'm using a custom personalized VM. But the only thing that is generating the error is the gzip header option on the http packet. Is that option deeply related or coupled to the vm? BTW, the error is a 400 from the server so i don't believe so.
No one else experimenting the same as me?
2012/10/31 Camillo Bruni <camillobruni@gmail.com> You say you cannot download from squeaksource in the latest 2.0 image?
We use that regularly, for instance for the NativeBoost build, and everything works fine (win / linux / mac)
That leaves me quite puzzled about the real cause of this bug...
On 2012-10-31, at 21:47, Guido Chari <charig@gmail.com> wrote:
Hi,
Since a couple of weeks i'm have not been able to download packages with Metacello on last image versions from Jenkins.
Today i found that if i revert changes on httpClient method from MCHttpRepository everything works fine again.
I haven't research deeply on why, i'm not an expert on Zinc, but the message that is breaking everything and making my image to receive a 400 error from squeaksource is setAcceptEncodingGzip that is addinng the gzip header to the requests.
As i said, i haven't going to deep with this but as i am the only one who is watching this behavior perhaps is something only for squeaksource.
If this is actually an issue and not some fault from myself, and someone give me some help, i can help with the solution.
Cheers, Guido.
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
On 2012-11-01, at 15:58, Guido Chari <charig@gmail.com> wrote:
Both tests succeed.
grml, maybe squeaksource falls under the argentinian import restriction as some sort of luxury goods :P Ok so another try with zinc? ZnClient new systemPolicy; url: 'http://smalltalkhub.com/mc/estebanlm/Voyage/main'; setAcceptEncodingGzip; beOneShot; get could there be a problem with zip support in your image/vm? Can you run all the Compression tests? thanks cami
I couldn't read at home so i couldn't test it without the proxy but i'm "almost sure" the proxy is not explaining the issue.
2012/11/1 Camillo Bruni <camillobruni@gmail.com>
could you try the following "benchmarks"
http://dev.nuclearrooster.com/2009/11/08/checking-gzipdeflate-server-respons...
with the following urls (just 2 projects): http://smalltalkhub.com/mc/estebanlm/Voyage/main http://squeaksource.com/NativeBoost/
both support gzip answers without problems.
On 2012-10-31, at 23:47, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Would it be possible to test without the transparant proxy ? From another location, like from home ? If this would fail for everyone, we would have heard about it much sooner.
On 31 Oct 2012, at 22:27, Guido Chari <charig@gmail.com> wrote:
Yes, since a couple of weeks i can't. I'm on a Unix now behind a transparent proxy. Same Vm, on same machine, behind the same proxy, no problem if strip out the gzip header from the packet.
I'm using a custom personalized VM. But the only thing that is generating the error is the gzip header option on the http packet. Is that option deeply related or coupled to the vm? BTW, the error is a 400 from the server so i don't believe so.
No one else experimenting the same as me?
2012/10/31 Camillo Bruni <camillobruni@gmail.com> You say you cannot download from squeaksource in the latest 2.0 image?
We use that regularly, for instance for the NativeBoost build, and everything works fine (win / linux / mac)
That leaves me quite puzzled about the real cause of this bug...
On 2012-10-31, at 21:47, Guido Chari <charig@gmail.com> wrote:
Hi,
Since a couple of weeks i'm have not been able to download packages with Metacello on last image versions from Jenkins.
Today i found that if i revert changes on httpClient method from MCHttpRepository everything works fine again.
I haven't research deeply on why, i'm not an expert on Zinc, but the message that is breaking everything and making my image to receive a 400 error from squeaksource is setAcceptEncodingGzip that is addinng the gzip header to the requests.
As i said, i haven't going to deep with this but as i am the only one who is watching this behavior perhaps is something only for squeaksource.
If this is actually an issue and not some fault from myself, and someone give me some help, i can help with the solution.
Cheers, Guido.
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
Sorry for the late answer. 2012/11/2 Camillo Bruni <camillobruni@gmail.com>
On 2012-11-01, at 15:58, Guido Chari <charig@gmail.com> wrote:
Both tests succeed.
grml, maybe squeaksource falls under the argentinian import restriction as some sort of luxury goods :P
Jeje. I don't think so, but....
Ok so another try with zinc?
ZnClient new systemPolicy; url: 'http://smalltalkhub.com/mc/estebanlm/Voyage/main'; setAcceptEncodingGzip; beOneShot; get
Failed.
could there be a problem with zip support in your image/vm? Can you run all the Compression tests?
Have only zip tests and they are green.
thanks cami
I'm starting to think this may be something strange proxy blocking for gzip content but it would be extremely strange. Guido
I couldn't read at home so i couldn't test it without the proxy but i'm "almost sure" the proxy is not explaining the issue.
2012/11/1 Camillo Bruni <camillobruni@gmail.com>
could you try the following "benchmarks"
http://dev.nuclearrooster.com/2009/11/08/checking-gzipdeflate-server-respons...
with the following urls (just 2 projects): http://smalltalkhub.com/mc/estebanlm/Voyage/main http://squeaksource.com/NativeBoost/
both support gzip answers without problems.
On 2012-10-31, at 23:47, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Would it be possible to test without the transparant proxy ? From another location, like from home ? If this would fail for everyone, we would have heard about it much sooner.
On 31 Oct 2012, at 22:27, Guido Chari <charig@gmail.com> wrote:
Yes, since a couple of weeks i can't. I'm on a Unix now behind a transparent proxy. Same Vm, on same machine, behind the same proxy, no problem if strip out the gzip header from the packet.
I'm using a custom personalized VM. But the only thing that is generating the error is the gzip header option on the http packet. Is
that
option deeply related or coupled to the vm? BTW, the error is a 400 from the server so i don't believe so.
No one else experimenting the same as me?
2012/10/31 Camillo Bruni <camillobruni@gmail.com> You say you cannot download from squeaksource in the latest 2.0 image?
We use that regularly, for instance for the NativeBoost build, and everything works fine (win / linux / mac)
That leaves me quite puzzled about the real cause of this bug...
On 2012-10-31, at 21:47, Guido Chari <charig@gmail.com> wrote:
Hi,
Since a couple of weeks i'm have not been able to download packages
with
Metacello on last image versions from Jenkins.
Today i found that if i revert changes on httpClient method from MCHttpRepository everything works fine again.
I haven't research deeply on why, i'm not an expert on Zinc, but the message that is breaking everything and making my image to receive a 400 error from squeaksource is setAcceptEncodingGzip that is addinng the gzip header to the requests.
As i said, i haven't going to deep with this but as i am the only one who is watching this behavior perhaps is something only for squeaksource.
If this is actually an issue and not some fault from myself, and someone give me some help, i can help with the solution.
Cheers, Guido.
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
well let's debug it together in 10 days ;) that's going to be easier ;) On 2012-11-06, at 14:00, Guido Chari <charig@gmail.com> wrote:
Sorry for the late answer.
2012/11/2 Camillo Bruni <camillobruni@gmail.com>
On 2012-11-01, at 15:58, Guido Chari <charig@gmail.com> wrote:
Both tests succeed.
grml, maybe squeaksource falls under the argentinian import restriction as some sort of luxury goods :P
Jeje. I don't think so, but....
Ok so another try with zinc?
ZnClient new systemPolicy; url: 'http://smalltalkhub.com/mc/estebanlm/Voyage/main'; setAcceptEncodingGzip; beOneShot; get
Failed.
could there be a problem with zip support in your image/vm? Can you run all the Compression tests?
Have only zip tests and they are green.
thanks cami
I'm starting to think this may be something strange proxy blocking for gzip content but it would be extremely strange.
Guido
I couldn't read at home so i couldn't test it without the proxy but i'm "almost sure" the proxy is not explaining the issue.
2012/11/1 Camillo Bruni <camillobruni@gmail.com>
could you try the following "benchmarks"
http://dev.nuclearrooster.com/2009/11/08/checking-gzipdeflate-server-respons...
with the following urls (just 2 projects): http://smalltalkhub.com/mc/estebanlm/Voyage/main http://squeaksource.com/NativeBoost/
both support gzip answers without problems.
On 2012-10-31, at 23:47, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Would it be possible to test without the transparant proxy ? From another location, like from home ? If this would fail for everyone, we would have heard about it much sooner.
On 31 Oct 2012, at 22:27, Guido Chari <charig@gmail.com> wrote:
Yes, since a couple of weeks i can't. I'm on a Unix now behind a transparent proxy. Same Vm, on same machine, behind the same proxy, no problem if strip out the gzip header from the packet.
I'm using a custom personalized VM. But the only thing that is generating the error is the gzip header option on the http packet. Is
that
option deeply related or coupled to the vm? BTW, the error is a 400 from the server so i don't believe so.
No one else experimenting the same as me?
2012/10/31 Camillo Bruni <camillobruni@gmail.com> You say you cannot download from squeaksource in the latest 2.0 image?
We use that regularly, for instance for the NativeBoost build, and everything works fine (win / linux / mac)
That leaves me quite puzzled about the real cause of this bug...
On 2012-10-31, at 21:47, Guido Chari <charig@gmail.com> wrote:
Hi,
Since a couple of weeks i'm have not been able to download packages
with
Metacello on last image versions from Jenkins.
Today i found that if i revert changes on httpClient method from MCHttpRepository everything works fine again.
I haven't research deeply on why, i'm not an expert on Zinc, but the message that is breaking everything and making my image to receive a 400 error from squeaksource is setAcceptEncodingGzip that is addinng the gzip header to the requests.
As i said, i haven't going to deep with this but as i am the only one who is watching this behavior perhaps is something only for squeaksource.
If this is actually an issue and not some fault from myself, and someone give me some help, i can help with the solution.
Cheers, Guido.
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
participants (3)
-
Camillo Bruni -
Guido Chari -
Sven Van Caekenberghe