GNU bug report logs - #43425
[PATCH] gnu: openblas: Update to 0.3.10.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43425 in the body.
You can then email your comments to 43425 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Greg Hogan <code <at> greghogan.com>
To: guix-patches <at> gnu.org
Subject: [PATCH] gnu: openblas: Update to 0.3.10.
Date: Tue, 15 Sep 2020 09:59:58 -0400

[Message part 1 (text/plain, inline)]

From 3b23f2a61b0a5b25389875441739a53bfe5d9aab Mon Sep 17 00:00:00 2001
From: Greg Hogan <code <at> 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

[Message part 2 (text/html, inline)]

Message #8 received at 43425 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <othacehe <at> gnu.org>
To: Greg Hogan <code <at> greghogan.com>
Cc: 43425 <at> debbugs.gnu.org
Subject: Re: [bug#43425] [PATCH] gnu: openblas: Update to 0.3.10.
Date: Thu, 17 Sep 2020 15:58:13 +0200

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

Message #11 received at 43425 <at> debbugs.gnu.org (full text, mbox):

From: Greg Hogan <code <at> greghogan.com>
To: Mathieu Othacehe <othacehe <at> gnu.org>
Cc: 43425 <at> debbugs.gnu.org
Subject: Re: [bug#43425] [PATCH] gnu: openblas: Update to 0.3.10.
Date: Thu, 17 Sep 2020 11:47:55 -0400

[Message part 1 (text/plain, inline)]

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 <at> 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 <at> 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
>

[Message part 2 (text/html, inline)]

Message #16 received at 43425-done <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <othacehe <at> gnu.org>
To: Greg Hogan <code <at> greghogan.com>
Cc: 43425-done <at> debbugs.gnu.org
Subject: Re: [bug#43425] [PATCH] gnu: openblas: Update to 0.3.10.
Date: Fri, 18 Sep 2020 09:10:11 +0200

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

Message #19 received at 43425 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <othacehe <at> gnu.org>
To: 43425 <at> debbugs.gnu.org
Cc: code <at> greghogan.com
Subject: Re: bug#43425: [PATCH] gnu: openblas: Update to 0.3.10.
Date: Fri, 18 Sep 2020 14:10:52 +0200

> 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

Message #22 received at 43425 <at> debbugs.gnu.org (full text, mbox):

From: Greg Hogan <code <at> greghogan.com>
To: Mathieu Othacehe <othacehe <at> gnu.org>
Cc: 43425 <at> debbugs.gnu.org
Subject: Re: bug#43425: [PATCH] gnu: openblas: Update to 0.3.10.
Date: Fri, 18 Sep 2020 10:01:40 -0400

[Message part 1 (text/plain, inline)]

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 <at> 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
>

[Message part 2 (text/html, inline)]

Message #25 received at 43425 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <othacehe <at> gnu.org>
To: Greg Hogan <code <at> greghogan.com>
Cc: 43425 <at> debbugs.gnu.org
Subject: Re: bug#43425: [PATCH] gnu: openblas: Update to 0.3.10.
Date: Fri, 18 Sep 2020 16:36:48 +0200

> 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

Message #28 received at 43425 <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <marius <at> gnu.org>
To: Mathieu Othacehe <othacehe <at> gnu.org>, Greg Hogan <code <at> greghogan.com>
Cc: 43425 <at> debbugs.gnu.org
Subject: Re: [bug#43425] [PATCH] gnu: openblas: Update to 0.3.10.
Date: Fri, 25 Sep 2020 21:02:49 +0200

[Message part 1 (text/plain, inline)]

Mathieu Othacehe <othacehe <at> 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.

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.