[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What to do when udpating a package ?
From: |
zimoun |
Subject: |
Re: What to do when udpating a package ? |
Date: |
Fri, 15 May 2020 15:36:28 +0200 |
Dear Edouard,
In complement to what Julien said. :-)
On Fri, 15 May 2020 at 13:36, Edouard Klein <address@hidden> wrote:
> - Some packages would not build, for reasons unrelated to the update of
> python-prompt-toolkit. Namely:
> - fdroidserver@1.1.1 will not build because of a failure of
> python-apache-libcloud@2.4.0
> - python-matplotlib-documentation@3.1.2 and
> python-ipython-documentation@7.9.0 will not build because of a failure
> of texlive-union-51265
> - python-rpy2@3.0.4-1.19868a8 would not build
> All those failure also happen on origin/master on my machine, and are
> therefore unrelated to the changes I made.
> --> Is any failure to build expected on origin/master ?
No, it is not expected.
As Forrest Gump says: "It happens, sometimes." :-)
> --> If so, where can I check the official build success/fail status of
> a package ?
Well, the link is ci.guix.gnu.org then top right, for example the query:
spec:guix-master system:x86_64-linux python-apache-libcloud
But personally I do not always understand what Cuirass reports.
Therefore, I prefer to use data.guix.gnu.org then for example:
http://data.guix.gnu.org/repository/1/branch/master/package/fdroidserver/output-history
I do not know the correct way to reach this webpage so I type directly
the URL -- well to be exact, I have an Emacs interactive function so I
type M-x my/guix-data fdroidserver RET and it opens the above webpage.
Then I click to one "Failed dependency" and I arrive to:
http://data.guix.gnu.org/build-server/1/build?derivation_file_name=/gnu/store/ccrk10g4vpzf6nk7x8j1a36s0b4z0w2l-fdroidserver-1.1.1.drv
and I can click to the failing derivation and then I arrive to
ci.guix.gnu.org and I can give a look to the raw log.
Well, I do not know if it is the correct way, but it is how I am doing
time to time to see what happens on the build farm. Be careful of
your current Guix version and the Guix version on ci you are
examining.
> --> If not, how can I check that my master version of guix is correct
> and is building everything it should build ?
I do not understand what you mean.
"guix weather" to see if the substitute is available.
"guix challenge" to compare your own builds to the builds on substitutes.
> --> In any case, how can I check that my change does not negatively
> affect these packages ?
Which packages? The ones which do not currently build?
> - Some of the failing-in-master packages do not depend directly on
> python-prompt toolkit, but they depend on a package that depends on
> etc.
> e.g. fdroidserver@1.1.1 depends on python-androguard@3.2.1 which
> depends on python-ipython@7.9.0.
> --> fdroidserver@1.1.1 fails to build for reasons unrelated to
> python-prompt-toolkit, but both python-androguard@3.2.1 and
> python-ipython@7.9.0. both build with the new version of
> python-prompt-toolkit. Would I be correct in assuming that
> frdoidserver would build with the new version ? I assume not, but I
> would like to be sure
I miss something about what depends on what. :-)
I do not have really the graph under my eyes. ;-)
> - python-iml@0.6.2 does not build with prompt-toolkit in version 3 (the
> version is explicitly stated as >=2.0 and <2.1 in the Python files), but
> when I add prompt-toolkit-2 to its propagated-inputs, it does.
> Given that python-ipython has prompt-toolkit (implicitly in version
> 3) installed in its propagated inputs, this means that any environment
> with python-iml will have prompt-toolkit in both its version 2 and 3
> installed at the same time. I feel uneasy about this.
> --> Is this a problem ?
> --> Should I just trust that if it builds, then everything is
> allright ?
No, it should pass the tests too. If there is tests. :-)
If not, you should install it locally and try it.
Because the package could build but should have runtime issues.
> --> Is there a way to check the graph to make the edges as
> sparse as possible (i.e. remove as many edges as possible without
> changing the reachability) ? Would this be something we want ?
> According to me it would because it would make the packages
> definitions shorter and the computations on the graph faster, but I'm
> not sure.
What do you mean by "reachability"?
There is a new feature to "guix graph": '--path'. You can find the
shortest path from one package to another, e.g.,
guix graph --path guix-jupyter python
What do you mean by "the edges as sparse as possible"?
All the best,
simon