Re: [build] fetch-depends having problems with the sourceforge mirror

[Mark Hindess <ma...@googlemail.com>]

In message <4C...@gmail.com>, Tim Ellison writes:
>
> On 24/Aug/2010 16:46, Sian January wrote:
> > On 19 August 2010 03:29, Tim Ellison <t....@gmail.com> wrote:
> >> On 18/Aug/2010 08:51, Sian January wrote:
> >>> I've just run the federated build from scratch and it all went
> >>> smoothly except that I had to change the sourceforge mirror in all the
> >>> depends.properties file.  Looking at their website [1] "internap"
> >>> doesn't seem to be listed at the moment so I think we may need to
> >>> switch the scripts to use a different one.  OVH worked for me
> >>> yesterday unless anyone has another preference?
> >> Almost by definition it is unlikely that any one mirror will satisfy
> >> everyone.
> >>
> >> It should be possible to specify the chosen SourceForge mirror site used
> >> at build time by defining the ant property -Dsf.base= though looking at
> >> the depends.properties file I see not all URLs have been rewritten to
> >> use that base property yet.
> >>
> >> I didn't see anything obvious for how to dynamically find your best
> >> mirror for using SF.
> > 
> > Looks like you can add ?use_mirror=autoselect to the end of the URL
> > 
> > e.g. http://downloads.sourceforge.net/sourceforge/mx4j/mx4j-3.0.2.zip?use_mirror=autoselect
> > 
> > Shall I update the build files to use this instead?
> 
> Sounds good, but let's wait until after the milestone to avoid any
> unforeseen problems that may appear with more testing.

I don't think we should release source artifacts that have obviously
broken fetch-depends URLs.  It would be confusing and inconvenient for
those trying to use these artifacts.  More importantly, none of my
automated scripts for creating the linux/debian artifacts will work and
doing them manually would be more error-prone and would require much
more time than I have available at the moment.

I don't mind if we don't fix all of the urls to use the mirror
auto-selection but I do think we need to fix them to point at a working
mirror.

We already use dfn.dl.sourceforge.net for some downloads so I suggest
just doing search/replace of internap with dfn on the problematic URLs.
Please can I have permission to commit this change?

Regards,
-Mark.

Re: [build] fetch-depends having problems with the sourceforge mirror

[sebb <se...@gmail.com>]

On 1 September 2010 13:45, Tim Ellison <t....@gmail.com> wrote:
> On 01/Sep/2010 11:53, Mark Hindess wrote:
>> In message <4C...@gmail.com>, Tim Ellison writes:
>>> On 24/Aug/2010 16:46, Sian January wrote:
>>>> On 19 August 2010 03:29, Tim Ellison <t....@gmail.com> wrote:
>>>>> On 18/Aug/2010 08:51, Sian January wrote:
>>>>>> I've just run the federated build from scratch and it all went
>>>>>> smoothly except that I had to change the sourceforge mirror in all the
>>>>>> depends.properties file.  Looking at their website [1] "internap"
>>>>>> doesn't seem to be listed at the moment so I think we may need to
>>>>>> switch the scripts to use a different one.  OVH worked for me
>>>>>> yesterday unless anyone has another preference?
>>>>> Almost by definition it is unlikely that any one mirror will satisfy
>>>>> everyone.
>>>>>
>>>>> It should be possible to specify the chosen SourceForge mirror site used
>>>>> at build time by defining the ant property -Dsf.base= though looking at
>>>>> the depends.properties file I see not all URLs have been rewritten to
>>>>> use that base property yet.
>>>>>
>>>>> I didn't see anything obvious for how to dynamically find your best
>>>>> mirror for using SF.
>>>> Looks like you can add ?use_mirror=autoselect to the end of the URL
>>>>
>>>> e.g. http://downloads.sourceforge.net/sourceforge/mx4j/mx4j-3.0.2.zip?use_mirror=autoselect
>>>>
>>>> Shall I update the build files to use this instead?
>>> Sounds good, but let's wait until after the milestone to avoid any
>>> unforeseen problems that may appear with more testing.
>>
>> I don't think we should release source artifacts that have obviously
>> broken fetch-depends URLs.  It would be confusing and inconvenient for
>> those trying to use these artifacts.  More importantly, none of my
>> automated scripts for creating the linux/debian artifacts will work and
>> doing them manually would be more error-prone and would require much
>> more time than I have available at the moment.
>>
>> I don't mind if we don't fix all of the urls to use the mirror
>> auto-selection but I do think we need to fix them to point at a working
>> mirror.
>>
>> We already use dfn.dl.sourceforge.net for some downloads so I suggest
>> just doing search/replace of internap with dfn on the problematic URLs.
>> Please can I have permission to commit this change?
>
> I thought it was a temporary outage that I've seen before, but it's been
> a while and the download from internap does seem to have disappeared.
>
> I'm +1 to switching to another mirror for now, and working with the
> autoselect mechanism after the milestone.

If a jar is available from Maven central, perhaps consider switching
to that instead?

e.g. in this case use

http://repo1.maven.org/maven2/mx4j/mx4j/3.0.2/

or one of the other mx4j Maven directories.

There will probably still be some jars that have to come from SF.

Re: [build] fetch-depends having problems with the sourceforge mirror

[Tim Ellison <t....@gmail.com>]

On 01/Sep/2010 11:53, Mark Hindess wrote:
> In message <4C...@gmail.com>, Tim Ellison writes:
>> On 24/Aug/2010 16:46, Sian January wrote:
>>> On 19 August 2010 03:29, Tim Ellison <t....@gmail.com> wrote:
>>>> On 18/Aug/2010 08:51, Sian January wrote:
>>>>> I've just run the federated build from scratch and it all went
>>>>> smoothly except that I had to change the sourceforge mirror in all the
>>>>> depends.properties file.  Looking at their website [1] "internap"
>>>>> doesn't seem to be listed at the moment so I think we may need to
>>>>> switch the scripts to use a different one.  OVH worked for me
>>>>> yesterday unless anyone has another preference?
>>>> Almost by definition it is unlikely that any one mirror will satisfy
>>>> everyone.
>>>>
>>>> It should be possible to specify the chosen SourceForge mirror site used
>>>> at build time by defining the ant property -Dsf.base= though looking at
>>>> the depends.properties file I see not all URLs have been rewritten to
>>>> use that base property yet.
>>>>
>>>> I didn't see anything obvious for how to dynamically find your best
>>>> mirror for using SF.
>>> Looks like you can add ?use_mirror=autoselect to the end of the URL
>>>
>>> e.g. http://downloads.sourceforge.net/sourceforge/mx4j/mx4j-3.0.2.zip?use_mirror=autoselect
>>>
>>> Shall I update the build files to use this instead?
>> Sounds good, but let's wait until after the milestone to avoid any
>> unforeseen problems that may appear with more testing.
> 
> I don't think we should release source artifacts that have obviously
> broken fetch-depends URLs.  It would be confusing and inconvenient for
> those trying to use these artifacts.  More importantly, none of my
> automated scripts for creating the linux/debian artifacts will work and
> doing them manually would be more error-prone and would require much
> more time than I have available at the moment.
> 
> I don't mind if we don't fix all of the urls to use the mirror
> auto-selection but I do think we need to fix them to point at a working
> mirror.
> 
> We already use dfn.dl.sourceforge.net for some downloads so I suggest
> just doing search/replace of internap with dfn on the problematic URLs.
> Please can I have permission to commit this change?

I thought it was a temporary outage that I've seen before, but it's been
a while and the download from internap does seem to have disappeared.

I'm +1 to switching to another mirror for now, and working with the
autoselect mechanism after the milestone.

Regards,
Tim