Fixing broken links for previous LibreOffice releases

classic Classic list List threaded Threaded
12 messages Options
William Gathoye William Gathoye
Reply | Threaded
Open this post in threaded view
|

Fixing broken links for previous LibreOffice releases

Hello everyone,

Like some of you know, I'm also working on some packages for the
Chocolatey community (the package manager for Windows). LibreOffice is
one of the package I maintain there.

I just wanted to know whether TDF would be open to make a redirection rule

  * from https://download.documentfoundation.org/libreoffice/stable/
  * to https://downloadarchive.documentfoundation.org/libreoffice/old/
  * *for files that are not found at*
    https://download.documentfoundation.org/libreoffice/stable/ (see it
    like a try_files in terms of NGINX)

_Why?_

Since the switch to the Fresh/Still branch, I have been facing a few
issues with my LibreOffice packages. I tried to fix them, but the
Chocolatey staff asked me to try to fix the issue upstream instead.

At Chocolatey the links to the LibreOffice Windows installers break when
the following use cases occur:

  * each time a LibreOffice branch becomes deprecated/renamed: e.g. when
    the fresh 6.1 became the still 6.1
  * each time a new version is released: e.g. 6.1.5 is released, 6.1.4
    is thus moved away from download.documentfoundation to
    downloadarchive.documentfoundation. Happened today with 6.2.0 being
    moved away since 6.2.2 has been just released.

In these cases, our LibreOffice Chocolatey packages become pointless
because previous versions cannot be installed by Chocolatey users.

_Why not fix the issue from Chocolatey?_

  * A Chocolatey package that has been published as a specific version
    cannot be republished again except if we suffix the version by the
    current date. This is annoying because if a user wants to install
    LibreOffice 6.1.4 for example, this won't work because the version
    will need to be suffixed and I'll need to know that suffix in
    advance e.g. 6.1.4.20190321.
  * Republishing all packages will trigger all the chocolatey unit tests
    against each package that has been updated. The Chocolatey CI queue
    will run for a very long time and will defer the queue for other
    packages as well. Packages could be republished in series rather
    than everything at once though.
  * Chocolatey has the ability to bundle installers inside the packages,
    why not use this feature? We are reaching the CDN limit here.
    Packages above 200Mio cannot be cached via our Cloudflare CDN. Plus,
    this will increase Chocolatey's storage costs.

_Why bother with old versions?_

This is the same question as why TDF is still keeping old binaries. Plus
the fact, speaking as a LibreOffice contributor, this is sometimes
easier to try to reproduce a Windows specific bug using chocolatey
rather than downloading each LibreOffice installer manually (even if I
know TDF is providing bibisect versions).

Thanks in advance for your help,

--
William Gathoye
<[hidden email]>


--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/website/
Privacy Policy: https://www.documentfoundation.org/privacy
Guilhem Moulin Guilhem Moulin
Reply | Threaded
Open this post in threaded view
|

Re: Fixing broken links for previous LibreOffice releases

Hi,

On Thu, 21 Mar 2019 at 15:22:20 +0100, William Gathoye wrote:
> I just wanted to know whether TDF would be open to make a redirection rule
>
> * from https://download.documentfoundation.org/libreoffice/stable/
> * to https://downloadarchive.documentfoundation.org/libreoffice/old/
> * *for files that are not found at*
>   https://download.documentfoundation.org/libreoffice/stable/ (see it
>   like a try_files in terms of NGINX)

That won't work without heavy changes to the download vhost, because the
version on download.documentfoundation.org is X.Y.Z, while the one on
downloadarchive.documentfoundation.org contains a point release number,
and the HTTPd doesn't know a priori which version to map to.

guilhem@download ~$ sha256sum libreoffice/stable/6.1.5*/win/x86_64/LibreOffice_6.1.5*_Win_x64.msi
812e01eaa790c8fa66c91254e9255ec494f22a92e8d18bfbe50486c842884289  libreoffice/stable/6.1.5/win/x86_64/LibreOffice_6.1.5_Win_x64.msi

guilhem@downloadarchive ~$ sha256sum libreoffice/old/6.1.5*/win/x86_64/LibreOffice_6.1.5*_Win_x64.msi
48d4cafceb0ac9d5a3fdbbe0b77bf641027a1860880bf3da4e1ca003301b1ca1  libreoffice/old/6.1.5.1/win/x86_64/LibreOffice_6.1.5.1_Win_x64.msi
812e01eaa790c8fa66c91254e9255ec494f22a92e8d18bfbe50486c842884289  libreoffice/old/6.1.5.2/win/x86_64/LibreOffice_6.1.5.2_Win_x64.msi

So today stable/6.1.5 is old/6.1.5.2.  But the suffix isn't constant, so
we would need to maintain a map.  OTOH for fresh the filename contains
the point release, and we have redirections already (from archive to
main not the other way around):

    $ curl -sw"%{http_code} %{redirect_url}\\n" \
        -o/dev/null -r0-1024 https://downloadarchive.documentfoundation.org/libreoffice/old/6.2.2.1/win/x86_64/LibreOffice_6.2.2.1_Win_x64.msi \
        -o/dev/null -r0-1024 https://downloadarchive.documentfoundation.org/libreoffice/old/6.2.2.2/win/x86_64/LibreOffice_6.2.2.2_Win_x64.msi
    206
    302 https://ftp.gwdg.de/pub/tdf/libreoffice/_testing_/6.2.2/win/x86_64/LibreOffice_6.2.2.2_Win_x64.msi

6.2.2.2 is present on the mirror network, so it's served from there.
OTOH 6.2.2.1 is served directly.

If you want specific versions, why not using https://downloadarchive.documentfoundation.org
instead of https://download.documentfoundation.org .  I suppose we could
add some redirects to stable too, to avoid serving still ourselves.

Cheers,
--
Guilhem.

--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/website/
Privacy Policy: https://www.documentfoundation.org/privacy
William Gathoye William Gathoye
Reply | Threaded
Open this post in threaded view
|

Re: Fixing broken links for previous LibreOffice releases


On 3/21/19 4:08 PM, Guilhem Moulin wrote:
>
> So today stable/6.1.5 is old/6.1.5.2.  But the suffix isn't constant, so
> we would need to maintain a map.

Yes, this is what I realized when I wrote the Powershell script for
Chocolatey that is taking care of this mapping [1].


> If you want specific versions, why not using https://downloadarchive.documentfoundation.org
> instead of https://download.documentfoundation.org .

Because (like I wrote in my previous message), this would require to
change all the URLs in each chocolatey packages, which we want to avoid
for multiple reasons (explained as well).

> I suppose we could
> add some redirects to stable too, to avoid serving still ourselves.

And why do we need two dedicated mirrors actually? If I understand
correctly you/TDF did it that way to:

  * only keep latest versions under CDN: i.e. download.documentfoundation
  * and archives served by TDF directly (without CDN then): i.e.
    downloadarchive.documentfoundation

Am I correct?

Which solution would be possible here?

  * either hardcode all the redirections (I already have the mapping
    between the links if needed)
  * or do you need to write some scripts to automate this process for
    future releases in your build system? I'm willing to help if needed
    here.
  * maybe another solution you have in mind?

Regards

[1] 
https://github.com/wget/chocolatey-coreteampackages/blob/fix-libreoffice-website-link/automatic/libreoffice-streams/update.ps1#L94

--
William Gathoye
<[hidden email]>


--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/website/
Privacy Policy: https://www.documentfoundation.org/privacy
Guilhem Moulin Guilhem Moulin
Reply | Threaded
Open this post in threaded view
|

Re: Fixing broken links for previous LibreOffice releases

On Thu, 21 Mar 2019 at 17:02:09 +0100, William Gathoye wrote:

>> I suppose we could
>> add some redirects to stable too, to avoid serving still ourselves.
>
> And why do we need two dedicated mirrors actually? If I understand
> correctly you/TDF did it that way to:
>
>  * only keep latest versions under CDN: i.e. download.documentfoundation
>  * and archives served by TDF directly (without CDN then): i.e.
>    downloadarchive.documentfoundation
>
> Am I correct?

Yes.
 
> Which solution would be possible here?
>
>  * either hardcode all the redirections (I already have the mapping
>    between the links if needed)
>  * or do you need to write some scripts to automate this process for
>    future releases in your build system? I'm willing to help if needed
>    here.

We have the >500k filenames (~117k of which starting with ‘libreoffice/stable/’,
~192k for ‘libreoffice/testing/’) ever seen by Mirrorbrain in a
database, along with their digests.

    SELECT f.path, h.sha256
      FROM filearr f JOIN hash h
        ON f.id = h.file_id
     WHERE f.path LIKE 'libreoffice/stable/%'
        OR f.path LIKE 'libreoffice/testing/%';

JOIN'ing (ON h.sha256) the result of that query with a similar one (on
downloadarchive) we should be able to populate a static map for
ngx_http_map_module.  That's likely to be more robust than a map
obtained by manually scrapping HTML :-P

I can certainly do that, but to be useful that map would need to be
automatically updated during the releng process, so I'll let cloph
decide if that's viable.

--
Guilhem.

--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/website/
Privacy Policy: https://www.documentfoundation.org/privacy
William Gathoye William Gathoye
Reply | Threaded
Open this post in threaded view
|

Re: Fixing broken links for previous LibreOffice releases


On 3/21/19 5:46 PM, Guilhem Moulin wrote:
>
> JOIN'ing (ON h.sha256) the result of that query with a similar one (on
> downloadarchive) we should be able to populate a static map for
> ngx_http_map_module.  That's likely to be more robust than a map
> obtained by manually scrapping HTML :-P

For sure, but how will be materialized this map table in practice, in
terms of links?

Will this solution avoid me to change all the links that point to
download.documentfoundation?

> I can certainly do that, but to be useful that map would need to be
> automatically updated during the releng process, so I'll let cloph
> decide if that's viable.

Yes. If you can update us of his answer in this list, as soon you get
more info that would be nice.


Also, I forgot to mention, but if you could offer a link that point to
the latest versions for both branch still and fresh, that would be nice
of you. Or at least something that can be parsed with ease (to determine
the latest version and link to these latest versions). Chocolatey and
Homebrew, both using a fragile parsing solution for LibreOffice, will
appreciate.

Regards,

--
William Gathoye
<[hidden email]>



--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/website/
Privacy Policy: https://www.documentfoundation.org/privacy
Guilhem Moulin Guilhem Moulin
Reply | Threaded
Open this post in threaded view
|

Re: Fixing broken links for previous LibreOffice releases

On Fri, 22 Mar 2019 at 12:46:12 +0100, William Gathoye wrote:
> On 3/21/19 5:46 PM, Guilhem Moulin wrote:
>> JOIN'ing (ON h.sha256) the result of that query with a similar one (on
>> downloadarchive) we should be able to populate a static map for
>> ngx_http_map_module.  That's likely to be more robust than a map
>> obtained by manually scrapping HTML :-P
>
> For sure, but how will be materialized this map table in practice, in
> terms of links?

Assuming a point in the future where 6.1.5, 6.2.1, and testing/6.2.2 are
no longer served by the mirror network, but stable/6.2.2 still is:

    curl -sw"%{http_code} %{redirect_url}\\n" \
        -o/dev/null https://download.documentfoundation.org/libreoffice/stable/6.1.5/mac/x86_64/LibreOffice_6.1.5_MacOS_x86-64.dmg \
        -o/dev/null https://download.documentfoundation.org/libreoffice/stable/6.2.1/deb/x86_64/LibreOffice_6.2.1_Linux_x86-64_deb.tar.gz \
        -o/dev/null https://download.documentfoundation.org/libreoffice/stable/6.2.2/win/x86/LibreOffice_6.2.2_Win_x86.msi \
        -o/dev/null https://download.documentfoundation.org/libreoffice/testing/6.2.2/win/x86/LibreOffice_6.2.2.2_Win_x86.msi
    302 https://downloadarchive.documentfoundation.org/libreoffice/old/6.1.5.2/mac/x86_64/LibreOffice_6.1.5.2_MacOS_x86-64.dmg
    302 https://downloadarchive.documentfoundation.org/libreoffice/old/6.2.1.2/deb/x86_64/LibreOffice_6.2.1.2_Linux_x86-64_deb.tar.gz
    302 $MIRROR_BASEURL/libreoffice/testing/6.2.2/win/x86/LibreOffice_6.2.2.2_Win_x86.msi
    302 https://downloadarchive.documentfoundation.org/libreoffice/old/6.2.2.2/win/x86/LibreOffice_6.2.2.2_Win_x86.msi

For the glory details, the map for ngx_http_map_module, populated from
the JOIN'ed queries:

    map $uri $archived_uri {
        "/libreoffice/stable/6.1.5/mac/x86_64/LibreOffice_6.1.5_MacOS_x86-64.dmg"        "/libreoffice/old/6.1.5.2/mac/x86_64/LibreOffice_6.1.5.2_MacOS_x86-64.dmg";
        "/libreoffice/stable/6.2.1/deb/x86_64/LibreOffice_6.2.1_Linux_x86-64_deb.tar.gz" "/libreoffice/old/6.2.1.2/deb/x86_64/LibreOffice_6.2.1.2_Linux_x86-64_deb.tar.gz";
        "/libreoffice/stable/6.2.2/win/x86/LibreOffice_6.2.2_Win_x86.msi"                "/libreoffice/old/6.2.2.2/win/x86/LibreOffice_6.2.2.2_Win_x86.msi";
        "/libreoffice/testing/6.2.2/win/x86/LibreOffice_6.2.2.2_Win_x86.msi"             "/libreoffice/old/6.2.2.2/win/x86/LibreOffice_6.2.2.2_Win_x86.msi";
        […]
    }

Then in a 404 handler for the proxy's status code (not tested):

    if ($archived_uri != "") {
        return 302 https://downloadarchive.documentfoundation.org$archived_uri;
    }
    return 404 /path/to/404.html;

>> I can certainly do that, but to be useful that map would need to be
>> automatically updated during the releng process, so I'll let cloph
>> decide if that's viable.
>
> Yes. If you can update us of his answer in this list, as soon you get
> more info that would be nice.

I assume he'll be reading this once he's back from vacation :-)
 
> Also, I forgot to mention, but if you could offer a link that point to
> the latest versions for both branch still and fresh, that would be nice
> of you. Or at least something that can be parsed with ease (to determine
> the latest version and link to these latest versions). Chocolatey and
> Homebrew, both using a fragile parsing solution for LibreOffice, will
> appreciate.

This was brought up during the Dec 2018 infra call, and rejected.  See
the minutes for the discussion.

--
Guilhem.

--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/website/
Privacy Policy: https://www.documentfoundation.org/privacy
William Gathoye William Gathoye
Reply | Threaded
Open this post in threaded view
|

Re: Fixing broken links for previous LibreOffice releases


On 3/22/19 3:55 PM, Guilhem Moulin wrote:
>
> Assuming a point in the future where 6.1.5, 6.2.1, and testing/6.2.2 are
> no longer served by the mirror network, but stable/6.2.2 still is:
>
>     curl -sw"%{http_code} %{redirect_url}\\n" \
>         -o/dev/null https://download.documentfoundation.org/libreoffice/stable/6.2.2/win/x86/LibreOffice_6.2.2_Win_x86.msi \
[...]
>     302 https://downloadarchive.documentfoundation.org/libreoffice/old/6.2.2.2/win/x86/LibreOffice_6.2.2.2_Win_x86.msi
Ok so the redirection seems to be transparent then? The
download.documentfoundation.org links won't change and everything (the
302) will be handled server-side.
> This was brought up during the Dec 2018 infra call, and rejected.  See
> the minutes for the discussion.

From my understanding, the reason hasn't be provided [1] but Cloph only
said this is already available if we do a request against the check
server (update.libreoffice.org) using a fake user agent.

I haven't been able to verify this assumption with the following command:

curl -A "some random user agent" -L http://update.libreoffice.org

[1] https://listarchives.libreoffice.org/global/website/msg15216.html


--
William Gathoye
<[hidden email]>



--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/website/
Privacy Policy: https://www.documentfoundation.org/privacy
Guilhem Moulin Guilhem Moulin
Reply | Threaded
Open this post in threaded view
|

Re: Fixing broken links for previous LibreOffice releases

On Fri, 22 Mar 2019 at 18:12:33 +0100, William Gathoye wrote:

> On 3/22/19 3:55 PM, Guilhem Moulin wrote:
>> Assuming a point in the future where 6.1.5, 6.2.1, and testing/6.2.2 are
>> no longer served by the mirror network, but stable/6.2.2 still is:
>>
>>  curl -sw"%{http_code} %{redirect_url}\\n" \
>>      -o/dev/null https://download.documentfoundation.org/libreoffice/stable/6.2.2/win/x86/LibreOffice_6.2.2_Win_x86.msi \
> [...]
>>  302 https://downloadarchive.documentfoundation.org/libreoffice/old/6.2.2.2/win/x86/LibreOffice_6.2.2.2_Win_x86.msi
>
> Ok so the redirection seems to be transparent then? The
> download.documentfoundation.org links won't change and everything (the
> 302) will be handled server-side.

As the command output suggests, yes.  Or at least that's what I propose,
assuming releng accept to maintain that map.

>> This was brought up during the Dec 2018 infra call, and rejected.  See
>> the minutes for the discussion.
>
> From my understanding, the reason hasn't be provided [1] but Cloph
> only said this is already available if we do a request against the
> check server (update.libreoffice.org) using a fake user agent.

Depends what “this” refers to.  There is no dictionary mapping
‘fresh’/‘still’ to download urls, let alone a 3XY redirect.  But if you
provide your build and a more recent version is available for that
flavor, you get some information about that update, incl. its build ID
and version number

> I haven't been able to verify this assumption with the following command:
>
> curl -A "some random user agent" -L http://update.libreoffice.org

Fake doesn't mean you can chose whatever you want :-P  But fair enough
the minutes don't mention the right User-Agent header value.  You need
to perform the queries made by your LibreOffice program, for instance

    GET /check.php HTTP/2
    Host: update.libreoffice.org
    User-Agent: LibreOffice 6.0.7.3 (dc89aa7a9eabfd848af146d5086077aeed2ae4a5; Windows; x86; )

Then select with XPATH ‘/inst:description/inst:version’ to retrieve the
version number to update to.  Or with a one-liner:

    curl -sSA "LibreOffice 6.0.7.3 (dc89aa7a9eabfd848af146d5086077aeed2ae4a5; Windows; x86; )" \
        https://update.libreoffice.org/check.php | xmlstarlet sel -T -t -v '/inst:description/inst:version'

(though you'll want to ensure that the output has a valid XML
description).  There is also an update URL (XPATH ‘/inst:description/inst:update/@src’)
but I suppose that's not what you want, because that (intentionally) links to
https://www.libreoffice.org/download not https://download.documentfoundation.org .

--
Guilhem.

--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/website/
Privacy Policy: https://www.documentfoundation.org/privacy
William Gathoye William Gathoye
Reply | Threaded
Open this post in threaded view
|

Re: Fixing broken links for previous LibreOffice releases


On 22/03/2019 19:04, Guilhem Moulin wrote:
>
> As the command output suggests, yes.  Or at least that's what I propose,
> assuming releng accept to maintain that map.
Let's have our fingers crossed hoping this will be possible to
implement/keep over the long term then :)
>
> Depends what “this” refers to.  There is no dictionary mapping
> ‘fresh’/‘still’ to download urls, let alone a 3XY redirect.  But if you
> provide your build and a more recent version is available for that
> flavor, you get some information about that update, incl. its build ID
> and version number
Hum ok. But in your example you specified a 6.0.x build and the server
answered the user should download 6.1.5.

This is weird because if someone has installed the 6.0 branch when that
one was the *fresh one*, he won't be proposed to download 6.2.2.

I'm thus wondering:

  * how the system performs the match between branches and how he keeps
    track of the branches (see issue described just above ^)
  * and (more interesting for my use case), how to have a build string
    that will always work. i.e. a build string that will answer with the
    latest version of the still branch and a build string that will
    answer with the latest version of the fresh branch. Because at
    chocolatey, the update script won't change (as the build id I'll fake).

>
>     curl -sSA "LibreOffice 6.0.7.3 (dc89aa7a9eabfd848af146d5086077aeed2ae4a5; Windows; x86; )" \
>         https://update.libreoffice.org/check.php | xmlstarlet sel -T -t -v '/inst:description/inst:version'
Ok perfect. Understood. I didn't know about xmlstarlet btw. Great tool!

--
William Gathoye
<[hidden email]>


--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/website/
Privacy Policy: https://www.documentfoundation.org/privacy
Guilhem Moulin Guilhem Moulin
Reply | Threaded
Open this post in threaded view
|

Re: Fixing broken links for previous LibreOffice releases

On Fri, 22 Mar 2019 at 22:15:17 +0100, William Gathoye wrote:
> I'm thus wondering:
>
> * how the system performs the match between branches and how he keeps
>   track of the branches (see issue described just above ^)
> * and (more interesting for my use case), how to have a build string
>   that will always work. i.e. a build string that will answer with the
>   latest version of the still branch and a build string that will
>   answer with the latest version of the fresh branch. Because at
>   chocolatey, the update script won't change (as the build id I'll fake).

No idea, that's a question for releng (cloph).  In the meantime you can
read the source:

    https://cgit.freedesktop.org/libreoffice/website/tree/check.php?h=update

(Note that I never claimed that using the update check system would
solve your use-case :-P)

--
Guilhem.

--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/website/
Privacy Policy: https://www.documentfoundation.org/privacy
William Gathoye William Gathoye
Reply | Threaded
Open this post in threaded view
|

Re: Fixing broken links for previous LibreOffice releases

Hello everyone,


On 22/03/2019 23:09, Guilhem Moulin wrote:
>
> No idea, that's a question for releng (cloph).

I'm coming back to the news.

Can cloph have a look at this?

Because as we don't have a solution right now, the problem is still
present at chocolatey [1] :/

Regards,


[1] https://chocolatey.org/packages/libreoffice-still#comment-4487551601

--
William Gathoye
<[hidden email]>



--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/website/
Privacy Policy: https://www.documentfoundation.org/privacy
Guilhem Moulin Guilhem Moulin
Reply | Threaded
Open this post in threaded view
|

Re: Fixing broken links for previous LibreOffice releases

Hi,

On Mon, 03 Jun 2019 at 20:54:44 +0200, William Gathoye wrote:
> On 22/03/2019 23:09, Guilhem Moulin wrote:
>> No idea, that's a question for releng (cloph).
>
> I'm coming back to the news.

This was on the Apr 18 infra call agenda, and closed as wontfix:

 * Preserve old download links (redirect to downloadarchive), cf. wget's mail
   + cloph: not keen to manually maintain a map for a single distro
   + switching the links to use downloadarchive instead of download might
     take time but that's just a one-off overhead

Sorry for not following up here :-P
--
Guilhem.

--
To unsubscribe e-mail to: [hidden email]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/website/
Privacy Policy: https://www.documentfoundation.org/privacy