From: Edouard Klein <edk@beaver-labs.com>
To: guix-devel <guix-devel@gnu.org>
Subject: Re: What to do when udpating a package ?
Date: Fri, 15 May 2020 17:43:03 +0200 [thread overview]
Message-ID: <87mu696w6w.fsf@alice.lan> (raw)
In-Reply-To: <CAJ3okZ1uqvsU9pvfxcOKMcQdUpGYFhGKznAEAwZhzHNtz1g_Nw@mail.gmail.com>
zimoun writes:
> Dear Edouard,
>
> In complement to what Julien said. :-)
>
>
> On Fri, 15 May 2020 at 13:36, Edouard Klein <edk@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.
next prev parent reply other threads:[~2020-05-15 15:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-15 7:20 What to do when udpating a package ? Edouard Klein
2020-05-15 12:26 ` Julien Lepiller
2020-05-15 15:32 ` Edouard Klein
2020-05-15 15:45 ` Julien Lepiller
2020-05-15 13:36 ` zimoun
2020-05-15 15:43 ` Edouard Klein [this message]
2020-05-15 16:17 ` zimoun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mu696w6w.fsf@alice.lan \
--to=edk@beaver-labs.com \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).