4.7.5 release

Hi there,

I want to release a 4.7.5 before Chistmas, but I am running
a bit low on 
time, so it might be next week. I've committed all the
issues with 
"ready to go" patches, but I think there are a few
bugs which would be 
nice to fix and need a review and testing:

http://drupal.org/node/
102962
http://drupal.org/node/8
7372
http://drupal.org/node/8
2397

and of course the rest of

http://drupal.org/project/issues?projects=3060&
amp;versions=97573,94735,94733,94731,94729,94720&sta
tes=8,13,14,15

Cheers,
	Gerhard

Gerhard Killesreiter wrote:
> Hi there,
> 
> I want to release a 4.7.5 before Chistmas, but I am
running a bit low on 
> time, so it might be next week. I've committed all the
issues with 
> "ready to go" patches, but I think there are
a few bugs which would be 
> nice to fix and need a review and testing:
> 
> http://drupal.org/node/
102962
> http://drupal.org/node/8
7372
> http://drupal.org/node/8
2397
> 
> and of course the rest of
> 
> http://drupal.org/project/issues?projects=3060&
amp;versions=97573,94735,94733,94731,94729,94720&sta
tes=8,13,14,15 
> 
> 

snf of courdse I forgot to mention that it would be helpful
if people 
could get the 4.7-CVS tarball or a CVS checkout and test it
so we knwo 
we don't ship a broken release.

http://drupal.org/
drupal-4.7.x-dev

Cheers,
      Gerhard

Gerhard,

I'm new to this particular task, so please forgive as I take
a few 
missteps on how to report problems.  Through my own
challenges I'm also 
locked out of my d.o user account right now*.  I've worked
over the 
issue queue and only this issue appears to be related to the
bug I found 
in 4.7.5: http://drupal.org/node/
104693

I just brought down the 4.7.5 through cvs up onto my site, 
www.folkjam.org.  I make heavy use of Google geocoding on
the site and 
it broke.  From what I can tell I am getting a timeout when
attempting 
to use drupal_http_request to maps.google.com.  I reverted
just 
common.inc to the version I was running and our Google
geocode requests 
began to work again.

Within common.inc:drupal_http_request() this is the change
that causes 
the problem:

  $request = $method .' '. $path ." HTTP/1.1rn";
is new

  $request = $method .' '. $path ." HTTP/1.0rn";
is what it was.

Using HTTP1.1 my request fails (it looks to time out) and
returns an 
empty result.  Using HTTP 1.0 my request works.

Sorry for using this forum to report the problem.  I'll get
myself back 
into d.o as soon as I learn how to configure mod_security
correctly.  
I'm picking security over being able to get into d.o right
now.

Scott

* A recent hosting provider move to dedicated hosting has a
new 
mod_security setup that blocks d.o authentication against my
personal 
site for federated login with error 406.  I'm new to
mod_security 
configuration.  I've worked out how to tell mod_security to
perform no 
security checks on /xmlrpc.php, but I have not yet worked
out how to 
tell it to perform no checks for 140.211.166.46 (d.o) but
check for 
everybody else.  I'm not willing to leave it open, so I'm
locked out of 
d.o until I fix this.  Which I'll get to.  If there is
anybody out there 
expert enough on mod_security to help, please contact me
off-list.

Gerhard Killesreiter wrote:
> Gerhard Killesreiter wrote:
>> Hi there,
>>
>> I want to release a 4.7.5 before Chistmas, but I am
running a bit low 
>> on time, so it might be next week. I've committed
all the issues with 
>> "ready to go" patches, but I think there
are a few bugs which would 
>> be nice to fix and need a review and testing:
>>
>> http://drupal.org/node/
102962
>> http://drupal.org/node/8
7372
>> http://drupal.org/node/8
2397
>>
>> and of course the rest of
>>
>> http://drupal.org/project/issues?projects=3060&
amp;versions=97573,94735,94733,94731,94729,94720&sta
tes=8,13,14,15 
>>
>>
>
> snf of courdse I forgot to mention that it would be
helpful if people 
> could get the 4.7-CVS tarball or a CVS checkout and
test it so we knwo 
> we don't ship a broken release.
>
> http://drupal.org/
drupal-4.7.x-dev
>
> Cheers,
>      Gerhard
>

Scott McLewin wrote:

Hi Scott!

> 
> I'm new to this particular task,

Welcome 

> so please forgive as I take a few 
> missteps on how to report problems.  Through my own
challenges I'm also 
> locked out of my d.o user account right now*.  I've
worked over the 
> issue queue and only this issue appears to be related
to the bug I found 
> in 4.7.5: http://drupal.org/node/
104693
> 

Thanks, I've reverted that patch.


> Sorry for using this forum to report the problem.  I'll
get myself back 
> into d.o as soon as I learn how to configure
mod_security correctly.  
> I'm picking security over being able to get into d.o
right now.
> 
> Scott
> 
> * A recent hosting provider move to dedicated hosting
has a new 
> mod_security setup that blocks d.o authentication
against my personal 
> site for federated login with error 406.  I'm new to
mod_security 
> configuration.  I've worked out how to tell
mod_security to perform no 
> security checks on /xmlrpc.php, but I have not yet
worked out how to 
> tell it to perform no checks for 140.211.166.46 (d.o)
but check for 

Drupal.org has two IPs, 140.211.166.46  and 140.211.166.61.

> everybody else.  I'm not willing to leave it open, so
I'm locked out of 
> d.o until I fix this.  Which I'll get to.  If there is
anybody out there 
> expert enough on mod_security to help, please contact
me off-list.

I think mod_security is a module that creates a lot of
difficult to 
track down problems...
Depending on configuration is breaks forms that contain
values that it 
disapproves of. Completely harmless values.

Cheers,
	Gerhard

Gerhard,
>> http://drupal.org/node/
104693
>>
>
> Thanks, I've reverted that patch.
Ok good.  I'll bring down 4.7.5 to our test site again and
continue to 
work it over.  One of our users reported what sounds like
the duplicate 
cookie sessions problem just last night.  I was pleased to
see that 
issue as one of the three you drew attention to
>
> Drupal.org has two IPs, 140.211.166.46  and
140.211.166.61.
Good to know.  I've got both in there now.  I was only ever
seeing the 
.46 one attempt to authenticate me.
>
> I think mod_security is a module that creates a lot of
difficult to 
> track down problems...
> Depending on configuration is breaks forms that contain
values that it 
> disapproves of. Completely harmless values.
That is a much nicer description than I would have given it.
 I leave it 
in because it's one of those things that I don't fully
understand, our 
provider's admin strongly recommends it be on, and I cannot
quantify the 
impact of not having it. 

Scott