[bug#43425] [PATCH] gnu: openblas: Update to 0.3.10.

[bug#43425] [PATCH] gnu: openblas: Update to 0.3.10.

[Greg Hogan]

[-- Attachment #1: Type: text/plain, Size: 1314 bytes --]

From 3b23f2a61b0a5b25389875441739a53bfe5d9aab Mon Sep 17 00:00:00 2001
From: Greg Hogan <code@greghogan.com>
Date: Mon, 14 Sep 2020 15:52:50 +0000
Subject: [PATCH] gnu: openblas: Update to 0.3.10.

* gnu/packages/maths.scm (openblas): Update to 0.3.10 and fetch from github.
---
 gnu/packages/maths.scm | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index df4d39f900..6a1d772318 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -3609,16 +3609,16 @@ parts of it.")
 (define-public openblas
   (package
     (name "openblas")
-    (version "0.3.9")
+    (version "0.3.10")
     (source
      (origin
        (method url-fetch)
-       (uri (string-append "mirror://sourceforge/openblas/v" version
"/OpenBLAS%20"
-                           version "%20version.tar.gz"))
+       (uri (string-append "https://github.com/xianyi/OpenBLAS/archive/v"
+                           version ".tar.gz"))
        (file-name (string-append name "-" version ".tar.gz"))
        (sha256
         (base32
-         "14iz9xnrb9xiwgj84j94mc74gg0zn2vsy9fmsijxxma1n7dck4w3"))))
+         "14qndvg229w2jh2di6n7d8kvw343yafsmv1fzx0qd6vyz1sx5104"))))
     (build-system gnu-build-system)
     (arguments
      `(#:test-target "test"
-- 
2.28.0

[-- Attachment #2: Type: text/html, Size: 1804 bytes --]

[bug#43425] [PATCH] gnu: openblas: Update to 0.3.10.

[Mathieu Othacehe]

Hello Greg,

> * gnu/packages/maths.scm (openblas): Update to 0.3.10 and fetch from github.

We prefer not to use the github archives that can be
regenerated. If it is really necessary to switch to github then you can
use the "git-fetch" method.

Could you please send an updated patch?

Thanks,

Mathieu

[bug#43425] [PATCH] gnu: openblas: Update to 0.3.10.

[Greg Hogan]

[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]

Mathieu,

Thank you for the recommendation. I had changed the source to the official
github repo to enable the version check by the refresh updater. Can the git
tag not be regenerated in the same way as archive uploads? New patch
follows.

Greg

From f02afcd187e7a11c84228f87a767094305f7f0eb Mon Sep 17 00:00:00 2001
From: Greg Hogan <code@greghogan.com>
Date: Thu, 17 Sep 2020 15:32:50 +0000
Subject: [PATCH] gnu: openblas: Update to 0.3.10.

* gnu/packages/maths.scm (openblas): Update to 0.3.10 and fetch from github.
---
 gnu/packages/maths.scm | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index df4d39f900..1ed1e0511b 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -3609,16 +3609,17 @@ parts of it.")
 (define-public openblas
   (package
     (name "openblas")
-    (version "0.3.9")
+    (version "0.3.10")
     (source
      (origin
-       (method url-fetch)
-       (uri (string-append "mirror://sourceforge/openblas/v" version
"/OpenBLAS%20"
-                           version "%20version.tar.gz"))
-       (file-name (string-append name "-" version ".tar.gz"))
+       (method git-fetch)
+       (uri (git-reference
+             (url "https://github.com/xianyi/OpenBLAS")
+             (commit (string-append "v" version))))
+       (file-name (git-file-name name version))
        (sha256
         (base32
-         "14iz9xnrb9xiwgj84j94mc74gg0zn2vsy9fmsijxxma1n7dck4w3"))))
+         "174id98ga82bhz2v7sy9yj6pqy0h0088p3mkdikip69p9rh3d17b"))))
     (build-system gnu-build-system)
     (arguments
      `(#:test-target "test"
-- 
2.28.0

On Thu, Sep 17, 2020 at 9:58 AM Mathieu Othacehe <othacehe@gnu.org> wrote:

>
> Hello Greg,
>
> > * gnu/packages/maths.scm (openblas): Update to 0.3.10 and fetch from
> github.
>
> We prefer not to use the github archives that can be
> regenerated. If it is really necessary to switch to github then you can
> use the "git-fetch" method.
>
> Could you please send an updated patch?
>
> Thanks,
>
> Mathieu
>

[-- Attachment #2: Type: text/html, Size: 2924 bytes --]

bug#43425: [PATCH] gnu: openblas: Update to 0.3.10.

[Mathieu Othacehe]

Hey,

> Thank you for the recommendation. I had changed the source to the
> official github repo to enable the version check by the refresh
> updater. Can the git tag not be regenerated in the same way as archive
> uploads? New patch follows.

Thanks for the updated version. Yes I guess it can happen but it's less
likely. I added your copyright and edited a bit the commit message
before applying.

Mathieu

-- 
https://othacehe.org

[bug#43425] [PATCH] gnu: openblas: Update to 0.3.10.

[Mathieu Othacehe]

> Thanks for the updated version. Yes I guess it can happen but it's less
> likely. I added your copyright and edited a bit the commit message
> before applying.

Turns out this patch causes 1912 package rebuilds. This is too much to
go to "master" branch.

This patch, as well as other patches you sent, such as the python
update, shall instead target "core-updates" branch as explained here:
https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html.

When it's the case do not hesitate to explicitly add "core-updates" to
the patch title so that committers forgetting to run `guix refresh -l
package`, such as myself do not choose the wrong branch :).

Thanks,

Mathieu

[bug#43425] [PATCH] gnu: openblas: Update to 0.3.10.

[Greg Hogan]

[-- Attachment #1: Type: text/plain, Size: 1613 bytes --]

Mathieu,

I was aware of the dependent-count triage but not fully understanding this
process. When are commits made to staging (last commit was the merge 13
days ago) and/or core-updates (one commit since merge 4 days ago)? I see
you were able to revert this commit to quiet the rebuilds, does this patch
now go into core-updates or is it queued somewhere else? Is there a
preferred time window for submitting highly-dependent revisions? I'm not
seeing 'staging' or 'core-updates' annotations among the git logs.

How often is the documentation regenerated? I see the limits changed in the
repo in June but the website has not been refreshed.

Is there a threshold for marking oneself in the copyright header? Such as,
a simple version and checksum revision is not copyrightable but further
changes must be marked?

Greg

On Fri, Sep 18, 2020 at 8:11 AM Mathieu Othacehe <othacehe@gnu.org> wrote:

>
> > Thanks for the updated version. Yes I guess it can happen but it's less
> > likely. I added your copyright and edited a bit the commit message
> > before applying.
>
> Turns out this patch causes 1912 package rebuilds. This is too much to
> go to "master" branch.
>
> This patch, as well as other patches you sent, such as the python
> update, shall instead target "core-updates" branch as explained here:
> https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html.
>
> When it's the case do not hesitate to explicitly add "core-updates" to
> the patch title so that committers forgetting to run `guix refresh -l
> package`, such as myself do not choose the wrong branch :).
>
> Thanks,
>
> Mathieu
>

[-- Attachment #2: Type: text/html, Size: 2279 bytes --]

[bug#43425] [PATCH] gnu: openblas: Update to 0.3.10.

[Mathieu Othacehe]

> I was aware of the dependent-count triage but not fully understanding this process. When are commits made to staging (last commit was the merge 13 days ago) and/or core-updates (one
> commit since merge 4 days ago)? I see you were able to revert this commit to quiet the rebuilds, does this patch now go into core-updates or is it queued somewhere else? Is there a
> preferred time window for submitting highly-dependent revisions? I'm not seeing 'staging' or 'core-updates' annotations among the git logs.

We have some time frames when "staging" and "core-updates" are
open. Then, those branches are stabilized before being merged to
"master". There's no specific schedule, but usually stabilization of
those branches is advertised on the mailing list.

Right now, I think that the window is open. I rebased your openblas
patch, as well as python, llvm, boost and zstd patches on top of
core-updates. It will take me a while to build those packages, but I'll
keep you informed.

> How often is the documentation regenerated? I see the limits changed
> in the repo in June but the website has not been refreshed.

I thought it was every hour, but the mechanism may be broken.

> Is there a threshold for marking oneself in the copyright header? Such as, a simple version and checksum revision is not copyrightable but further changes must be marked?

I always forget if a copyright addition is required for a simple
update. We should definitely add this information to the "Submitting
Patches" section.

Thanks,

Mathieu

[bug#43425] [PATCH] gnu: openblas: Update to 0.3.10.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 531 bytes --]

Mathieu Othacehe <othacehe@gnu.org> writes:

>> How often is the documentation regenerated? I see the limits changed
>> in the repo in June but the website has not been refreshed.
>
> I thought it was every hour, but the mechanism may be broken.

The manual for the current version of Guix is available at:

  https://guix.gnu.org/manual/devel/

The "normal" manual link will always point to the latest release
(currently 1.1.0) because otherwise there might be incompatibilities
between published documentation and the installer.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]