[PATCH 0/6] Use 'download.libvirt.org' on our webpage
Peter Krempa (6): docs: java: Clean up links to source code docs: downloads: Replace 'libvirt.org/sources' by 'download.libvirt.org' spec: Use 'download.libvirt.org' as source server docs: downloads: Change sources link for libvirt-ocaml docs: downloads: Drop link to sources of 'consoleproxy' docs: downloads: Point to gitlab for go module sources docs/downloads.rst | 39 ++++++++++++++++++++------------------- docs/java.rst | 9 ++++----- libvirt.spec.in | 2 +- 3 files changed, 25 insertions(+), 25 deletions(-) -- 2.39.2
- drop the link to the FTP server which doesn't exist any more - change links to libvirt.org/source to download.libvirt.org - change link to the maven repository to point to download.libvirt.org Signed-off-by: Peter Krempa <pkrempa@redhat.com> --- docs/java.rst | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/docs/java.rst b/docs/java.rst index df846c6fc6..949a7f4b83 100644 --- a/docs/java.rst +++ b/docs/java.rst @@ -16,11 +16,10 @@ Getting it The latest versions of the libvirt Java bindings can be downloaded from: -- `libvirt.org FTP server <ftp://libvirt.org/libvirt/java/>`__ -- `libvirt.org HTTP server <https://libvirt.org/sources/java/>`__ +- `libvirt.org HTTP server <https://download.libvirt.org/java/>`__ -A maven repository is located at https://libvirt.org/maven2/ which you can use -to include this in your maven projects. +A maven repository is located at https://download.libvirt.org/maven2/ which you +can use to include this in your maven projects. GIT source repository --------------------- @@ -68,7 +67,7 @@ become There is of course some functions where the mapping is less direct and using extra classes to map complex arguments. The -`Javadoc <https://libvirt.org/sources/java/javadoc>`__ is available online or as +`Javadoc <https://download.libvirt.org/java/javadoc>`__ is available online or as part of a separate libvirt-java-javadoc package. So let's look at a simple example inspired from the ``test.java`` test found in -- 2.39.2
On Tue, Mar 14, 2023 at 10:36:53AM +0100, Peter Krempa wrote:
There is of course some functions where the mapping is less direct and using extra classes to map complex arguments. The -`Javadoc <https://libvirt.org/sources/java/javadoc>`__ is available online or as +`Javadoc <https://download.libvirt.org/java/javadoc>`__ is available online or as part of a separate libvirt-java-javadoc package.
The Javadoc appears to be hopelessly outdated[1]. We should look into either ensuring that it's kept up to date as new releases are made or get rid of it. Reviewed-by: Andrea Bolognani <abologna@redhat.com> [1] <!-- Generated by javadoc on Fri Jul 06 10:27:49 CEST 2012--> -- Andrea Bolognani / Red Hat / Virtualization
We split off the downloads into a new subdomain. Link directly to it instead of relying on redirects. Signed-off-by: Peter Krempa <pkrempa@redhat.com> --- docs/downloads.rst | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/docs/downloads.rst b/docs/downloads.rst index e32fd1ba99..2a02c6a482 100644 --- a/docs/downloads.rst +++ b/docs/downloads.rst @@ -24,7 +24,7 @@ Libvirt - Resources * - libvirt - - `libvirt <https://libvirt.org/sources/>`__ + - `libvirt <https://download.libvirt.org/>`__ - `gitlab <https://gitlab.com/libvirt/libvirt>`__ - `issues <https://gitlab.com/libvirt/libvirt/-/issues>`__ - `github <https://github.com/libvirt/libvirt>`__ @@ -45,7 +45,7 @@ Language bindings - Resources * - C# - - `libvirt <https://libvirt.org/sources/csharp/>`__ + - `libvirt <https://download.libvirt.org/csharp/>`__ - `gitlab <https://gitlab.com/libvirt/libvirt-csharp>`__ - `issues <https://gitlab.com/libvirt/libvirt-csharp/-/issues>`__ - `github <https://github.com/libvirt/libvirt-csharp>`__ @@ -59,14 +59,14 @@ Language bindings - `api ref <https://pkg.go.dev/libvirt.org/go/libvirt>`__ * - Java - - `libvirt <https://libvirt.org/sources/java/>`__ + - `libvirt <https://download.libvirt.org/java/>`__ - `gitlab <https://gitlab.com/libvirt/libvirt-java>`__ - `issues <https://gitlab.com/libvirt/libvirt-java/-/issues>`__ - `github <https://github.com/libvirt/libvirt-java>`__ - * - OCaml - - `libvirt <https://libvirt.org/sources/ocaml/>`__ + - `libvirt <https://download.libvirt.org/ocaml/>`__ - `gitlab <https://gitlab.com/libvirt/libvirt-ocaml>`__ - `issues <https://gitlab.com/libvirt/libvirt-ocaml/-/issues>`__ - `github <https://github.com/libvirt/libvirt-ocaml>`__ @@ -81,14 +81,14 @@ Language bindings `changes <https://libvirt.org/git/?p=libvirt-perl.git;a=blob;f=Changes;hb=HEAD>`__ * - PHP - - `libvirt <https://libvirt.org/sources/php/>`__ + - `libvirt <https://download.libvirt.org/php/>`__ - `gitlab <https://gitlab.com/libvirt/libvirt-php>`__ - `issues <https://gitlab.com/libvirt/libvirt-php/-/issues>`__ - `github <https://github.com/libvirt/libvirt-php>`__ - * - Python - - `libvirt <https://libvirt.org/sources/python/>`__ + - `libvirt <https://download.libvirt.org/python/>`__ `pypi <https://pypi.python.org/pypi/libvirt-python>`__ - `gitlab <https://gitlab.com/libvirt/libvirt-python>`__ - `issues <https://gitlab.com/libvirt/libvirt-python/-/issues>`__ @@ -96,7 +96,7 @@ Language bindings - * - Ruby - - `libvirt <https://libvirt.org/sources/ruby/>`__ + - `libvirt <https://download.libvirt.org/ruby/>`__ - `gitlab <https://gitlab.com/libvirt/libvirt-ruby>`__ - `issues <https://gitlab.com/libvirt/libvirt-ruby/-/issues>`__ - `github <https://github.com/libvirt/libvirt-ruby>`__ @@ -123,7 +123,7 @@ Integration modules - Resources * - GLib / GConfig / GObject - - `libvirt <https://libvirt.org/sources/glib/>`__ + - `libvirt <https://download.libvirt.org/glib/>`__ - `gitlab <https://gitlab.com/libvirt/libvirt-glib>`__ - `issues <https://gitlab.com/libvirt/libvirt-glib/-/issues>`__ - `github <https://github.com/libvirt/libvirt-glib>`__ @@ -137,42 +137,42 @@ Integration modules - `api ref <https://pkg.go.dev/libvirt.org/go/libvirtxml>`__ * - D-Bus - - `libvirt <https://libvirt.org/sources/dbus/>`__ + - `libvirt <https://download.libvirt.org/dbus/>`__ - `gitlab <https://gitlab.com/libvirt/libvirt-dbus>`__ - `issues <https://gitlab.com/libvirt/libvirt-dbus/-/issues>`__ - `github <https://github.com/libvirt/libvirt-dbus>`__ - * - Console Proxy - - `libvirt <https://libvirt.org/sources/consoleproxy/>`__ + - `libvirt <https://download.libvirt.org/consoleproxy/>`__ - `gitlab <https://gitlab.com/libvirt/libvirt-console-proxy>`__ - `issues <https://gitlab.com/libvirt/libvirt-console-proxy/-/issues>`__ - `github <https://github.com/libvirt/libvirt-console-proxy>`__ - * - CIM provider - - `libvirt <https://libvirt.org/sources/CIM/>`__ + - `libvirt <https://download.libvirt.org/CIM/>`__ - `gitlab <https://gitlab.com/libvirt/libvirt-cim>`__ - `issues <https://gitlab.com/libvirt/libvirt-cim/-/issues>`__ - `github <https://github.com/libvirt/libvirt-cim>`__ - * - CIM utils - - `libvirt <https://libvirt.org/sources/CIM/>`__ + - `libvirt <https://download.libvirt.org/CIM/>`__ - `gitlab <https://gitlab.com/libvirt/libcmpiutil>`__ - `issues <https://gitlab.com/libvirt/libcmpiutil/-/issues>`__ - `github <https://github.com/libvirt/libcmpiutil>`__ - * - SNMP - - `libvirt <https://libvirt.org/sources/snmp/>`__ + - `libvirt <https://download.libvirt.org/snmp/>`__ - `gitlab <https://gitlab.com/libvirt/libvirt-snmp>`__ - `issues <https://gitlab.com/libvirt/libvirt-snmp/-/issues>`__ - `github <https://github.com/libvirt/libvirt-snmp>`__ - * - Application Sandbox - - `libvirt <https://libvirt.org/sources/sandbox/>`__ + - `libvirt <https://download.libvirt.org/sandbox/>`__ - `gitlab <https://gitlab.com/libvirt/libvirt-sandbox>`__ - `issues <https://gitlab.com/libvirt/libvirt-sandbox/-/issues>`__ - `github <https://github.com/libvirt/libvirt-sandbox>`__ @@ -191,7 +191,7 @@ Testing - GIT Mirrors * - TCK - - `libvirt <https://libvirt.org/sources/tck/>`__ + - `libvirt <https://download.libvirt.org/tck/>`__ - `gitlab <https://gitlab.com/libvirt/libvirt-tck>`__ - `issues <https://gitlab.com/libvirt/libvirt-tck/-/issues>`__ - `github <https://github.com/libvirt/libvirt-tck>`__ @@ -252,7 +252,7 @@ Most modules have releases made available for download on the project site via HTTPS. Some modules are instead made available at alternative locations, for example, the Perl binding is made available only on CPAN. -- `libvirt.org HTTPS server <https://libvirt.org/sources/>`__ +- `libvirt.org HTTPS server <https://download.libvirt.org/>`__ Primary release schedule ------------------------ @@ -354,7 +354,7 @@ following key is currently used to generate the GPG signatures: Fingerprint=453B 6531 0595 5628 5547 1199 CA68 BE80 1008 4C9C It can be downloaded from `this -site <https://libvirt.org/sources/gpg_key.asc>`__ or from public GPG key +site <https://download.libvirt.org/gpg_key.asc>`__ or from public GPG key servers. Releases prior to libvirt-6.6 were signed with the following GPG key: -- 2.39.2
On Tue, Mar 14, 2023 at 10:36:54AM +0100, Peter Krempa wrote:
We split off the downloads into a new subdomain. Link directly to it instead of relying on redirects.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> --- docs/downloads.rst | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-)
Reviewed-by: Andrea Bolognani <abologna@redhat.com> -- Andrea Bolognani / Red Hat / Virtualization
Signed-off-by: Peter Krempa <pkrempa@redhat.com> --- libvirt.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index e62534c31d..cdca418401 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -236,7 +236,7 @@ URL: https://libvirt.org/ %if %(echo %{version} | grep -q "\.0$"; echo $?) == 1 %define mainturl stable_updates/ %endif -Source: https://libvirt.org/sources/%{?mainturl}libvirt-%{version}.tar.xz +Source: https://download.libvirt.org/%{?mainturl}libvirt-%{version}.tar.xz Requires: libvirt-daemon = %{version}-%{release} Requires: libvirt-daemon-config-network = %{version}-%{release} -- 2.39.2
On Tue, Mar 14, 2023 at 10:36:55AM +0100, Peter Krempa wrote:
Signed-off-by: Peter Krempa <pkrempa@redhat.com> --- libvirt.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Andrea Bolognani <abologna@redhat.com> -- Andrea Bolognani / Red Hat / Virtualization
The sources for new libvirt-ocaml releases are hosted via gitlab. Add the link. Since old releases are not present there preserve also the old link. Signed-off-by: Peter Krempa <pkrempa@redhat.com> --- docs/downloads.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/downloads.rst b/docs/downloads.rst index 2a02c6a482..bf64b45715 100644 --- a/docs/downloads.rst +++ b/docs/downloads.rst @@ -66,7 +66,8 @@ Language bindings - * - OCaml - - `libvirt <https://download.libvirt.org/ocaml/>`__ + - `gitlab <https://gitlab.com/libvirt/libvirt-ocaml/-/tags>`__ + `libvirt (old versions) <https://download.libvirt.org/ocaml/>`__ - `gitlab <https://gitlab.com/libvirt/libvirt-ocaml>`__ - `issues <https://gitlab.com/libvirt/libvirt-ocaml/-/issues>`__ - `github <https://github.com/libvirt/libvirt-ocaml>`__ -- 2.39.2
On Tue, Mar 14, 2023 at 10:36:56AM +0100, Peter Krempa wrote:
The sources for new libvirt-ocaml releases are hosted via gitlab. Add the link. Since old releases are not present there preserve also the old link. ... * - OCaml - - `libvirt <https://download.libvirt.org/ocaml/>`__ + - `gitlab <https://gitlab.com/libvirt/libvirt-ocaml/-/tags>`__ + `libvirt (old versions) <https://download.libvirt.org/ocaml/>`__
Is the fact that no tarballs have been uploaded for the last few releases intentional, or an oversight? While I see tags for those releases in GitLab, in general git tags are not a replacement for proper release tarballs, which I'm not seeing anywhere on GitLab. The Fedora package still points to the libvirt.org server too[1], so to me it appears that a few uploads were simply missed. Rich? [1] https://src.fedoraproject.org/rpms/ocaml-libvirt/c/2559c77a711c7d82aef5110e4... -- Andrea Bolognani / Red Hat / Virtualization
On Tue, Mar 14, 2023 at 06:12:33AM -0400, Andrea Bolognani wrote:
On Tue, Mar 14, 2023 at 10:36:56AM +0100, Peter Krempa wrote:
The sources for new libvirt-ocaml releases are hosted via gitlab. Add the link. Since old releases are not present there preserve also the old link. ... * - OCaml - - `libvirt <https://download.libvirt.org/ocaml/>`__ + - `gitlab <https://gitlab.com/libvirt/libvirt-ocaml/-/tags>`__ + `libvirt (old versions) <https://download.libvirt.org/ocaml/>`__
Is the fact that no tarballs have been uploaded for the last few releases intentional, or an oversight?
While I see tags for those releases in GitLab, in general git tags are not a replacement for proper release tarballs, which I'm not seeing anywhere on GitLab.
Indeed, as was seen recently with github, the auto-generated tarballs can change when the backend impl changes, which invalidate any hashes vendors are using to validate tarballs. It is unwise to rely on the auto-generated tarballs as the canonical release artifacts
The Fedora package still points to the libvirt.org server too[1], so to me it appears that a few uploads were simply missed.
Rich?
[1] https://src.fedoraproject.org/rpms/ocaml-libvirt/c/2559c77a711c7d82aef5110e4... -- Andrea Bolognani / Red Hat / Virtualization
With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, Mar 14, 2023 at 10:14:33 +0000, Daniel P. Berrangé wrote:
On Tue, Mar 14, 2023 at 06:12:33AM -0400, Andrea Bolognani wrote:
On Tue, Mar 14, 2023 at 10:36:56AM +0100, Peter Krempa wrote:
The sources for new libvirt-ocaml releases are hosted via gitlab. Add the link. Since old releases are not present there preserve also the old link. ... * - OCaml - - `libvirt <https://download.libvirt.org/ocaml/>`__ + - `gitlab <https://gitlab.com/libvirt/libvirt-ocaml/-/tags>`__ + `libvirt (old versions) <https://download.libvirt.org/ocaml/>`__
Is the fact that no tarballs have been uploaded for the last few releases intentional, or an oversight?
While I see tags for those releases in GitLab, in general git tags are not a replacement for proper release tarballs, which I'm not seeing anywhere on GitLab.
Indeed, as was seen recently with github, the auto-generated tarballs can change when the backend impl changes, which invalidate any hashes vendors are using to validate tarballs. It is unwise to rely on the auto-generated tarballs as the canonical release artifacts
The Fedora package still points to the libvirt.org server too[1], so to me it appears that a few uploads were simply missed.
Rich?
In the following comment: https://gitlab.com/libvirt/libvirt-ocaml/-/issues/3#note_1292266414 Rich specifically pointed users to the gitlab "release".
On Tue, Mar 14, 2023 at 11:29:06AM +0100, Peter Krempa wrote:
On Tue, Mar 14, 2023 at 10:14:33 +0000, Daniel P. Berrangé wrote:
On Tue, Mar 14, 2023 at 06:12:33AM -0400, Andrea Bolognani wrote:
On Tue, Mar 14, 2023 at 10:36:56AM +0100, Peter Krempa wrote:
The sources for new libvirt-ocaml releases are hosted via gitlab. Add the link. Since old releases are not present there preserve also the old link. ... * - OCaml - - `libvirt <https://download.libvirt.org/ocaml/>`__ + - `gitlab <https://gitlab.com/libvirt/libvirt-ocaml/-/tags>`__ + `libvirt (old versions) <https://download.libvirt.org/ocaml/>`__
Is the fact that no tarballs have been uploaded for the last few releases intentional, or an oversight?
While I see tags for those releases in GitLab, in general git tags are not a replacement for proper release tarballs, which I'm not seeing anywhere on GitLab.
Indeed, as was seen recently with github, the auto-generated tarballs can change when the backend impl changes, which invalidate any hashes vendors are using to validate tarballs. It is unwise to rely on the auto-generated tarballs as the canonical release artifacts
The Fedora package still points to the libvirt.org server too[1], so to me it appears that a few uploads were simply missed.
Rich?
In the following comment:
https://gitlab.com/libvirt/libvirt-ocaml/-/issues/3#note_1292266414
Rich specifically pointed users to the gitlab "release".
Well version 0.6.1.5, which is the latest one available on libvirt.org, is PGP signed by Rich himself, so at some point in the past we clearly got this to work :) Could he have lost his access or something? -- Andrea Bolognani / Red Hat / Virtualization
On Tue, Mar 14, 2023 at 06:36:38 -0400, Andrea Bolognani wrote:
On Tue, Mar 14, 2023 at 11:29:06AM +0100, Peter Krempa wrote:
On Tue, Mar 14, 2023 at 10:14:33 +0000, Daniel P. Berrangé wrote:
[...]
The Fedora package still points to the libvirt.org server too[1], so to me it appears that a few uploads were simply missed.
Rich?
In the following comment:
https://gitlab.com/libvirt/libvirt-ocaml/-/issues/3#note_1292266414
Rich specifically pointed users to the gitlab "release".
Well version 0.6.1.5, which is the latest one available on libvirt.org, is PGP signed by Rich himself, so at some point in the past we clearly got this to work :)
The makefile even has specific code that does this upload as one of the targets.
Could he have lost his access or something?
Given the comment I linked to I thought the release process has somehow changed and the makefile wasn't updated. I didn't want to investigate much more than to try to decouple the webpages so that in the end we can host also the libvirt's page from gitlab pages.
On Tue, Mar 14, 2023 at 12:11:07PM +0100, Peter Krempa wrote:
On Tue, Mar 14, 2023 at 06:36:38 -0400, Andrea Bolognani wrote:
Well version 0.6.1.5, which is the latest one available on libvirt.org, is PGP signed by Rich himself, so at some point in the past we clearly got this to work :)
The makefile even has specific code that does this upload as one of the targets.
Could he have lost his access or something?
Given the comment I linked to I thought the release process has somehow changed and the makefile wasn't updated.
I didn't want to investigate much more than to try to decouple the webpages so that in the end we can host also the libvirt's page from gitlab pages.
Yeah, I think we need to figure out and agree on a way forward for libvirt-ocaml releases, but while we wait for that to happen you can already push all the ACKed patches and effectively complete the transition to the separate download server, thus allowing you to move forward with transfering libvirt.org to GitLab Pages. -- Andrea Bolognani / Red Hat / Virtualization
On Tue, Mar 14, 2023 at 08:43:48 -0400, Andrea Bolognani wrote:
On Tue, Mar 14, 2023 at 12:11:07PM +0100, Peter Krempa wrote:
On Tue, Mar 14, 2023 at 06:36:38 -0400, Andrea Bolognani wrote:
Well version 0.6.1.5, which is the latest one available on libvirt.org, is PGP signed by Rich himself, so at some point in the past we clearly got this to work :)
The makefile even has specific code that does this upload as one of the targets.
Could he have lost his access or something?
Given the comment I linked to I thought the release process has somehow changed and the makefile wasn't updated.
I didn't want to investigate much more than to try to decouple the webpages so that in the end we can host also the libvirt's page from gitlab pages.
Yeah, I think we need to figure out and agree on a way forward for libvirt-ocaml releases, but while we wait for that to happen you can already push all the ACKed patches and effectively complete the transition to the separate download server, thus allowing you to move forward with transfering libvirt.org to GitLab Pages.
I've posted v2 where I've simply dropped this patch. I need to patch libvirt-ocaml's page now because I've added similar wording there when I was adding it and that one was already merged.
On Tue, Mar 14, 2023 at 10:14:33AM +0000, Daniel P. Berrangé wrote:
On Tue, Mar 14, 2023 at 06:12:33AM -0400, Andrea Bolognani wrote:
On Tue, Mar 14, 2023 at 10:36:56AM +0100, Peter Krempa wrote:
The sources for new libvirt-ocaml releases are hosted via gitlab. Add the link. Since old releases are not present there preserve also the old link. ... * - OCaml - - `libvirt <https://download.libvirt.org/ocaml/>`__ + - `gitlab <https://gitlab.com/libvirt/libvirt-ocaml/-/tags>`__ + `libvirt (old versions) <https://download.libvirt.org/ocaml/>`__
Is the fact that no tarballs have been uploaded for the last few releases intentional, or an oversight?
While I see tags for those releases in GitLab, in general git tags are not a replacement for proper release tarballs, which I'm not seeing anywhere on GitLab.
Indeed, as was seen recently with github, the auto-generated tarballs can change when the backend impl changes, which invalidate any hashes vendors are using to validate tarballs. It is unwise to rely on the auto-generated tarballs as the canonical release artifacts
Not only that: you also miss all the stuff generated during the dist step, so the forge-generated tarballs are going to be unusable or at the very least require additional steps on the user's part. Plus no PGP signatures, which libvirt-ocaml seems to have finally started using recently. -- Andrea Bolognani / Red Hat / Virtualization
The directory doesn't exist. The project also doesn't have any releases on gitlab so there's nothing to replace it with. Signed-off-by: Peter Krempa <pkrempa@redhat.com> --- docs/downloads.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/downloads.rst b/docs/downloads.rst index bf64b45715..ed280e18c6 100644 --- a/docs/downloads.rst +++ b/docs/downloads.rst @@ -145,7 +145,7 @@ Integration modules - * - Console Proxy - - `libvirt <https://download.libvirt.org/consoleproxy/>`__ + - - `gitlab <https://gitlab.com/libvirt/libvirt-console-proxy>`__ - `issues <https://gitlab.com/libvirt/libvirt-console-proxy/-/issues>`__ - `github <https://github.com/libvirt/libvirt-console-proxy>`__ -- 2.39.2
On Tue, Mar 14, 2023 at 10:36:57AM +0100, Peter Krempa wrote:
The directory doesn't exist. The project also doesn't have any releases on gitlab so there's nothing to replace it with.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> --- docs/downloads.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
libvirt-csharp is in a similar situation, with the only difference being that we actually have a (completely empty) directory for it on libvirt.org. I would say that we should deal with that project the same way as this one. Reviewed-by: Andrea Bolognani <abologna@redhat.com> -- Andrea Bolognani / Red Hat / Virtualization
On Tue, Mar 14, 2023 at 06:15:39 -0400, Andrea Bolognani wrote:
On Tue, Mar 14, 2023 at 10:36:57AM +0100, Peter Krempa wrote:
The directory doesn't exist. The project also doesn't have any releases on gitlab so there's nothing to replace it with.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> --- docs/downloads.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
libvirt-csharp is in a similar situation, with the only difference being that we actually have a (completely empty) directory for it on libvirt.org. I would say that we should deal with that project the same way as this one.
I thought about that too. Here it was very clear as this link is a 404.
Currently the 'Releases' column pointed to the generic page about the specific go module. Change the link to point to the gitlab tags page. Signed-off-by: Peter Krempa <pkrempa@redhat.com> --- docs/downloads.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/downloads.rst b/docs/downloads.rst index ed280e18c6..605a8025e0 100644 --- a/docs/downloads.rst +++ b/docs/downloads.rst @@ -52,7 +52,7 @@ Language bindings - * - Go - - `libvirt <https://libvirt.org/go/libvirt>`__ + - `gitlab <https://gitlab.com/libvirt/libvirt-go-module/-/tags>`__ - `gitlab <https://gitlab.com/libvirt/libvirt-go-module>`__ - `issues <https://gitlab.com/libvirt/libvirt-go-module/-/issues>`__ - `github <https://github.com/libvirt/libvirt-go-module>`__ @@ -131,7 +131,7 @@ Integration modules - * - Go XML - - `libvirt <https://libvirt.org/go/libvirtxml>`__ + - `gitlab <https://gitlab.com/libvirt/libvirt-go-xml-module/-/tags>`__ - `gitlab <https://gitlab.com/libvirt/libvirt-go-xml-module>`__ - `issues <https://gitlab.com/libvirt/libvirt-go-xml-module/-/issues>`__ - `github <https://github.com/libvirt/libvirt-go-xml-module>`__ -- 2.39.2
On Tue, Mar 14, 2023 at 10:36:58AM +0100, Peter Krempa wrote:
* - Go - - `libvirt <https://libvirt.org/go/libvirt>`__ + - `gitlab <https://gitlab.com/libvirt/libvirt-go-module/-/tags>`__ - `gitlab <https://gitlab.com/libvirt/libvirt-go-module>`__ - `issues <https://gitlab.com/libvirt/libvirt-go-module/-/issues>`__ - `github <https://github.com/libvirt/libvirt-go-module>`__ @@ -131,7 +131,7 @@ Integration modules -
* - Go XML - - `libvirt <https://libvirt.org/go/libvirtxml>`__ + - `gitlab <https://gitlab.com/libvirt/libvirt-go-xml-module/-/tags>`__ - `gitlab <https://gitlab.com/libvirt/libvirt-go-xml-module>`__ - `issues <https://gitlab.com/libvirt/libvirt-go-xml-module/-/issues>`__ - `github <https://github.com/libvirt/libvirt-go-xml-module>`__
For these two, I think linking to https://pkg.go.dev/libvirt.org/go/libvirt https://pkg.go.dev/libvirt.org/go/libvirtxml similarly to how we point to the language-specific package repository for Python, Perl and Rust might make more sense. On the other hand, in the case of Go we don't explicitly publish releases to a different system, they get picked up automatically from the git tags... Dan? -- Andrea Bolognani / Red Hat / Virtualization
On Tue, Mar 14, 2023 at 06:20:48AM -0400, Andrea Bolognani wrote:
On Tue, Mar 14, 2023 at 10:36:58AM +0100, Peter Krempa wrote:
* - Go - - `libvirt <https://libvirt.org/go/libvirt>`__ + - `gitlab <https://gitlab.com/libvirt/libvirt-go-module/-/tags>`__ - `gitlab <https://gitlab.com/libvirt/libvirt-go-module>`__ - `issues <https://gitlab.com/libvirt/libvirt-go-module/-/issues>`__ - `github <https://github.com/libvirt/libvirt-go-module>`__ @@ -131,7 +131,7 @@ Integration modules -
* - Go XML - - `libvirt <https://libvirt.org/go/libvirtxml>`__ + - `gitlab <https://gitlab.com/libvirt/libvirt-go-xml-module/-/tags>`__ - `gitlab <https://gitlab.com/libvirt/libvirt-go-xml-module>`__ - `issues <https://gitlab.com/libvirt/libvirt-go-xml-module/-/issues>`__ - `github <https://github.com/libvirt/libvirt-go-xml-module>`__
For these two, I think linking to
https://pkg.go.dev/libvirt.org/go/libvirt https://pkg.go.dev/libvirt.org/go/libvirtxml
similarly to how we point to the language-specific package repository for Python, Perl and Rust might make more sense.
On the other hand, in the case of Go we don't explicitly publish releases to a different system, they get picked up automatically from the git tags...
Maybe better to use the versions page https://pkg.go.dev/libvirt.org/go/libvirt?tab=versions With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, Mar 14, 2023 at 10:23:15AM +0000, Daniel P. Berrangé wrote:
On Tue, Mar 14, 2023 at 06:20:48AM -0400, Andrea Bolognani wrote:
On Tue, Mar 14, 2023 at 10:36:58AM +0100, Peter Krempa wrote:
* - Go - - `libvirt <https://libvirt.org/go/libvirt>`__ + - `gitlab <https://gitlab.com/libvirt/libvirt-go-module/-/tags>`__ - `gitlab <https://gitlab.com/libvirt/libvirt-go-module>`__ - `issues <https://gitlab.com/libvirt/libvirt-go-module/-/issues>`__ - `github <https://github.com/libvirt/libvirt-go-module>`__ @@ -131,7 +131,7 @@ Integration modules -
* - Go XML - - `libvirt <https://libvirt.org/go/libvirtxml>`__ + - `gitlab <https://gitlab.com/libvirt/libvirt-go-xml-module/-/tags>`__ - `gitlab <https://gitlab.com/libvirt/libvirt-go-xml-module>`__ - `issues <https://gitlab.com/libvirt/libvirt-go-xml-module/-/issues>`__ - `github <https://github.com/libvirt/libvirt-go-xml-module>`__
For these two, I think linking to
https://pkg.go.dev/libvirt.org/go/libvirt https://pkg.go.dev/libvirt.org/go/libvirtxml
similarly to how we point to the language-specific package repository for Python, Perl and Rust might make more sense.
On the other hand, in the case of Go we don't explicitly publish releases to a different system, they get picked up automatically from the git tags...
Maybe better to use the versions page
Yeah, that could work too and would be a fitting counterpart for the directory listing that we present for projects where releases are stored on libvirt.org. On the other hand, for Python and Rust we point to the main package page instead of the version history subpage, which looks a bit better as a landing page. Perl doesn't seem to have a separate page for version history - it's all integrated in the small drop-down in the landing page. All in all, while both would be reasonable choices I have a slight preference for pointing to the landing page. -- Andrea Bolognani / Red Hat / Virtualization
participants (3)
-
Andrea Bolognani -
Daniel P. Berrangé -
Peter Krempa