zimoun writes:
> Dear Edouard, > > In complement to what Julien said. :-) > > > On Fri, 15 May 2020 at 13:36, Edouard Klein <e...@beaver-labs.com> 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." :-) > I was worried I had misconfigured my local version of guix. > >> --> 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. > I could not find the link to the raw log, but having access to the "official" build status is a huge relief, as I can stop worrying that the build failure is my fault. This is exactly what I was looking for. Thank you ! > > 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. > > I was asking how to make sure that my local guix is OK (I had trouble getting it to work). >> --> 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? Yeah, I'm worried maybe once the current build failure cause is addressed, my change will prevent them from building. > > >> - 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. Yeah, installing does not work :D See my answer to Julien > 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"? > > So if A depends on B and C, and B also depends on C, which is preferable as far as explicit input declarations in the packages code go: -- A->B; B->C; -- or A->B; A->C; B->C; -- The reachability (in the graph theoretical sense https://en.wikipedia.org/wiki/Reachability) is the same, but one graph has one edge less and is thus "minimal". If I understood Julien correctly he seems to think that the fully connected case is better (easier maintainability). > > All the best, > simon Thank you for your time, Cheers, Edouard.