Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)
Hello, Ricardo Wurmus writes: > Giovanni Biscuolo writes: > >> I still have to learn how to find a guix commit giving me one of those >> specific derivations... or just check if one specific commit provides >> one of those > > You generally can’t do that. You can’t compute the commit from only a > derivation file name. I guess that ‘guix weather’ checks the presence of substitutes for a current derivation of a package definition, so if in the same environment ‘guix weather’ tells that a substitute is available and ‘guix package’ doesn't fetch it, it sounds fishy no? Thanks. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)
Hello,
Ricardo Wurmus writes:
> Hi Giovanni,
>
>> I think my specific problem is caused by the "Gateway Timeout" error
>> from ci.guix.info, see below for details
>
> I cannot reproduce this.
I can reproduce here (on GuixSD) and like Giovanni I am unable to use
the substitutes for ‘ungoogled-chromium’.
--8<---cut here---start->8---
$ guix weather --manifest=foo.scm
calcul de 1 dérivations de paquets pour x86_64-linux…
recherche de 1 éléments du dépôt sur https://ci.guix.info...
https://ci.guix.info
100.0% substituts disponibles (1 sur 1)
99,3 Mo de fichiers nar (compressés)
288,3 Mo sur le disque (décompressé)
0,003 secondes par requête (0,0 secondesen tout)
358,9 requêtes par seconde
« https://ci.guix.info/api/queue?nr=1000 » a renvoyé 504 ("Gateway Time-out")
$ guix package -i ungoogled-chromium
construction de
/gnu/store/w54r150nj8ksyznj6b8q92fgr1n0l20h-ungoogled-chromium-72.0.3626.109.tar.xz.drv...
\ C-c C-c
--8<---cut here---end--->8---
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Promoting the GNU Kind Communication Guidelines?
Hello Ricardo, Ricardo Wurmus writes: >> Mathieu Lirzin skribis: >> >>> Following the announcement made by RMS regarding the new GNU Kind >>> Communication Guidelines (GKCG) [1], I would like to know if the Guix >>> developpers in particular its maintainers would agree to adopt it in >>> place of the current Code of Conduct (CoC)? >> >> Speaking for myself: no. I think the GKCG fails to address important >> issues, such as defining what’s acceptable and what’s not as well as >> clear processes to address this. > > [Apologies for the delay; I’m currently traveling.] No need to apology, your response is still prompt. :-) > Adding to what Ludovic wrote, I also would not want to replace the > current proven Contributor Covenant with the recently emerged GKCG. > Using *both* of them would not be useful, I think, as I find our current > CoC to be sufficient; using *only* the GKCG and dropping the existing > CoC would be a mistake in my opinion, as our CoC describes a process > which the GKCG does not. AIUI the GKCG is an attempt to reconcile people of the GNU hackers community which is has been fragmented by the CoC debate. In order to reconcile, each “camp” has to make some tradeoffs. Since you are a CoC proponent, it is normal that you feel that the GKCG is not as “good” as the CoC. However I would really appreciate if you (and Ludo) could seriously consider the GKCG “downsides” as an acceptable tradeoff to help uniting GNU Hackers and move the GNU project as a whole (not just the Guix project) towards what you consider the “right” direction in the “harassment free” path. >>> Adopting the GKCG instead of a CoC would help attracting people >>> (like me) who agree to use a welcoming and respectful language which >>> encourages everyone to contribute but are reluctant in contributing >>> to any project following a CoC due to its punitive nature and the >>> politics of its authors [2][3]. > > To me the politics of the author(s) of the original or current version > of the Contributor Covenant don’t play much of a role in prefering it as > a practical guiding document for this community. (I don’t know the > author.) Have you consider that it doesn't play a role because you basically share similar political ideas as the author(s) without knowing/caring? This is not intended as a critic, but just as an opportunity for you to consider that your own political bias (which we humans all have) is not universal and that maybe other “respectable” persons might not share it. > I think I see how it could be seen as “punitive”, but I don’t share this > assessment. We all want what’s best for the project and the people who > currently work on or consider working on it — to me the emergence of the > GKCG is more evidence that this is true. I hope that seeing these > similarities in intent more than the differences in implementation will > allow you to overcome your feeling of reluctance to contribute to Guix > (and other projects that have decided to adopt a CoC). As explain above, I don't think the CoC and GKCG has the same intent. If it were the case that Guix choose to ignore this opportunity to reconcile, I am sorry to say that my reluctance to contribute to Guix would not diminish. Thanks for you answer. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Promoting the GNU Kind Communication Guidelines?
Hello Ludo, l...@gnu.org (Ludovic Courtès) writes: > Mathieu Lirzin skribis: > >> Following the announcement made by RMS regarding the new GNU Kind >> Communication Guidelines (GKCG) [1], I would like to know if the Guix >> developpers in particular its maintainers would agree to adopt it in >> place of the current Code of Conduct (CoC)? > > Speaking for myself: no. I think the GKCG fails to address important > issues, such as defining what’s acceptable and what’s not as well as > clear processes to address this. I am sad that you feels that the GKCG is not sufficient for defining the acceptable behavior of the members of a Free Software community. >> Adopting the GKCG instead of a CoC would help attracting people (like >> me) who agree to use a welcoming and respectful language which >> encourages everyone to contribute but are reluctant in contributing to >> any project following a CoC due to its punitive nature and the politics >> of its authors [2][3]. > > Codes of conduct codify acceptable behavior and formalize processes: > what can I do as a contributor if I’m a victim bad behavior or > harassment? What are the group communication rules? What if I > knowingly break those rules? > > By adopting the code of conduct, we maintainers committed to spend our > time as needed to so your experience contributing to Guix won’t be a > source of stress or worse, as is too often the case in on-line > communities. > > The GKCG do not do that. Problems will be dealt with in an ad hoc > fashion (as they already are in groups that have not codified rules), if > they are addressed at all. > > I hope this answers your question. Yes it does perfectly. I personnaly think dealing with such issues in an ad hoc fashion is the right approach when acceptable behaviors are the norm, which IME has been the case. Anyway I still hope that the Guix community will eventually accept the GKCG as an acceptable tradeoff in the CoC debate. Thanks. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Promoting the GNU Kind Communication Guidelines?
Hello Tobias, Tobias Geerinckx-Rice writes: > I've (re-)read the links you've provided (thanks). I guess it's > supposed to be obvious what you find disagreeable about them, but if > one doesn't disagree, it's not that obvious. :-) IMO Discussing what I find disagreeable with the particular form of Feminism advocated by the links I have provided is off topic. Without direspecting those who agrees with those ideas, I think it is reasonably obvious that not everybody supporting Free Software, supports those unrelated political ideas. > That said, I hope we can address any perceived lack of merit in (our > copy of) the CoC without resorting to its original authors. The > resulting irony blast would level multiple city blocks. I don't understand the last sentence. Can you explain it with simpler words? >> [1] http://lists.gnu.org/archive/html/info-gnu/2018-10/msg1.html >> [2] https://www.contributor-covenant.org/ >> [3] https://geekfeminism.wikia.com/wiki/Meritocracy Thanks. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Promoting the GNU Kind Communication Guidelines?
Hello, Following the announcement made by RMS regarding the new GNU Kind Communication Guidelines (GKCG) [1], I would like to know if the Guix developpers in particular its maintainers would agree to adopt it in place of the current Code of Conduct (CoC)? Adopting the GKCG instead of a CoC would help attracting people (like me) who agree to use a welcoming and respectful language which encourages everyone to contribute but are reluctant in contributing to any project following a CoC due to its punitive nature and the politics of its authors [2][3]. Thanks. [1] http://lists.gnu.org/archive/html/info-gnu/2018-10/msg1.html [2] https://www.contributor-covenant.org/ [3] https://geekfeminism.wikia.com/wiki/Meritocracy -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: [GSoC] Development of Cuirass.
Hi, Mathieu Lirzin writes: > Here is my proposal for the Google Summer of Code 2017. I have updated it, according to the various feedback I had. Here is the link: http://mathieu.lirzin.emi.u-bordeaux.fr/gsoc/guix.html I must say that given the current agitation in Guix community for gender related issues, I am sorry to say that I withdraw my proposal. A majority of people in this community seems to adhere to political ideas related to feminism and LGBT causes and are very vocal about it. While I respect people having such conviction, the fact that those ideas/values are repeatedly presented as if every one should adhere to them is not welcoming for those who disagree. As a consequence I would rather spend my time working on Free Software projects that I consider more tolerant. Thanks. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: [GSoC] Development of Cuirass.
Hello, Andy Wingo writes: > On Sun 12 Mar 2017 15:49, Mathieu Lirzin writes: > >> Here is my proposal for the Google Summer of Code 2017. > > Looks great to me. FWIW I think you may want to use Fibers in Cuirass. > Sometimes a web API request might need to "fork" off a number of tasks, > and Fibers lets you do that pretty easily, and provides nice > communications mechanisms for inter-fiber communication like channels > and condition variables. It also prevents one long API request from > starving other API users. Also its abstractions are thread-safe, and it > enables parallel speedups by using all available cores. > > Right now Fibers doesn't have explicit support for subprocess events > like child-died, etc, though it can do concurrent access to multiple > pipes at once. So there's some work to do here. > > A reference: > > https://github.com/wingo/fibers/wiki/Manual > > Specifically see the "web server" notes in the Examples section. Fibers > is in Guix as "guile-fibers". Looks interesting. The web server that uses the standard interface seems not that difficult to integrate. I will add that to the road-map. Thanks. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: [GSoC] Development of Cuirass.
Hi, l...@gnu.org (Ludovic Courtès) writes: >> 2.1 The testing infrastructure >> ── >> >> Currently Cuirass is providing a small test suite consisting only of >> unit tests. The integration tests are done manually with basic >> examples consisting in building small packages such as GNU Hello. >> This is not good, because actual packages take a consequent time to >> compile, and testing only basic examples leaves the interesting >> complex case out of the scope of testing. The worst is that the >> result depend on the phase of the moon since every commit in Guix can >> potentially break the build. >> >> The idea is to take inspiration from the Guix test suite by providing >> tiny mocked packages that will help having lightweight build >> specifications. Those tests require launching another instance of the >> `guix-daemon' with a local temporary store. > > Sounds like a good idea. > > It would be nice to refine what it is we’re trying to test and that’s > not addressed by unit tests. At one end of the spectrum, I imagine we > could be spawning a couple of GuixSD VMs connected together, one serving > a Git repo, and the other one running Cuirass pulling from that repo (a > system test). > > At the middle of the spectrum is something like you describe, I think: > run Cuirass directly upon “make check”, though there are complications: > what repo do we pull from, do we really want to build packages and if > not how to we mock builds, etc. The idea I had was to create fake vcs repositories programmatically. I imagine that it is possible to associate some dummy build script that we can deterministically make fail. > There are several components we’d like to test more closely IMO: SCM > polling, evaluation, and job scheduling. Perhaps some of that can also > be achieved through unit tests? Yeah, that would be better. >> 2.2 HTTP API >> >> >> Since commit [12d71ee098c3eb84a9a5dc2419bd37a3b9e55dd2] Cuirass has a >> web server which is running in a separate thread of the `cuirass' >> process. However the resources it provides are pretty limited since >> you can only query the lists of specifications currently watched. >> This is done with the `/specifications' or `/jobsets' resource names. >> "Jobsets" is the terminology used by Hydra and is used here for >> compatibility with its HTTP API. > > For a start, I think we should implement all or a subset of the Hydra > API, as-is (it’s currently used by Emacs-Guix): > > https://github.com/NixOS/hydra/blob/master/src/lib/Hydra/Controller/API.pm > > A large part of it is about monitoring the status of Hydra: queued > builds, recently-completed builds, jobs, etc. That is the most pressing > need, I think. OK. >> This roadmap lacks details about the concrete tasks and its associated >> timeline. However I prefer having some feedback about this proposal >> first, before providing a complete roadmap. >> >> • From May 30 to June 26, I will work on the testing infrastructure,. >> • From June 27 to August 29, I will work on the HTTP API. > > You may find that you’ll want to interleave tasks. I don’t know about > you, but sometimes I get bored if I keep working on the same task or > domain for too long, so switching to something else for a while can be a > relief. :-) I don't know, I have been rarely confronted to that issue personnaly (more the opposite: too much context switching). But I will preventively adapt my roadmap. > There are a couple of isolated tasks that come to mind, which do not > really fit in the proposal but are worth looking into as time permits: > > • improved error reporting upon evaluation failures and so on; > > • improved error recovery; I totally forgot to precise that the error handling issue is exactly the reason I think we need a better test infrastructure for Cuirass. Being able to reproduce various errors or failues allows a better confidence in the error being properly handled. I find it hard to just imagine and write the appropriate handler. > • use of Guile-Git instead of Git. I Will add this to the plan. Thanks. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: [GSoC] Development of Cuirass.
"pelzflorian (Florian Pelz)" writes: > On 03/12/2017 07:41 PM, Mathieu Lirzin wrote: >> Hello Florian, >> >> "pelzflorian (Florian Pelz)" writes: >> >>> On 03/12/2017 03:49 PM, Mathieu Lirzin wrote: >>>> Sensitive requests should be done with an >>>> authentification mechanism which is not determined yet. I currently >>>> have no experience with any and lack the knowledge to properly choose >>>> one. >>> >>> I’m new to Guix and Scheme and no expert in Web programming, but in >>> order to prevent CSRF and in order not to rely on JavaScript, the server >>> should run with HTTPS (of course) and >>> · use a secret session token and >>> · send a customized Web page to the client adapted so that each link and >>> form to the server includes the session token as a GET or POST parameter. >>> >>> An alternative is Basic Access Authentication with HTTPS or Cookies with >>> HTTPS but they are vulnerable to CSRF. >>> >>> See stackoverflow, for example >>> >>> https://stackoverflow.com/questions/21357182/csrf-token-necessary-when-using-stateless-sessionless-authentication >> >> Thanks for your input. >> >> Have you any experience/advice regarding OAuth or Json Web Token (JWT) ? >> > > Sorry, I have no experience with these. I think I’ve basically > understood what OAuth is for after reading the OSM wiki, [1] but I’m not > sure what you want to use it for. > > I assume the following scenario: > > > The user wants to log in. > > · The Cuirass Web server would receive the log-in credentials as POST > parameters from an HTML form. > > · Now it needs to check whether the password is correct, e.g. by looking > up the salt stored for the supplied username, computing the bcrypt hash > of the supplied password and stored salt and comparing it to the stored > bcrypt hash for the user name.← This requires Cuirass to store a > table containing user names, salts and bcrypt hashes. Do you intend to > use some OAuth / OpenID / whatever thing to outsource the log-in > management to an “identity provider”? I presume you don’t. > > · You generate a secret session token shared between server and client > which you > — embed in each link and in each form you send to the client as part > of the session and > — can verify the session token on the server.← I did not know > about JWT, but from a first glance it seems very appropriate for this > use. Instead of storing on the server which sessions are still active, > the token stores all information about the log-in and its content is > encrypted with the server’s secret key. This seems like a great idea, > also there maybe is (or should be) a library to manage JWT. I learned > something today. :) I need to do my homework before being able to go further in this discussion. Thanks for you analysis. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: [PATCH 4/4] services: openssh: Add 'subsystems' option.
ng0 writes: > John Darrington transcribed 2.0K bytes: > >> I am glad that at least one person can express a point of view and be >> polite about >> it at the same time. If you think it is fine, then it is your right to use >> it. >> >> I find it confusing and clunky in most cases, and I refuse to use it.I >> also >> reserve the right, when others advocate its use, to present my own point of >> view. >> >> If anyone chooses to interpret that as rude, sexist, intolerant or >> whatever - then >> that is their problem and not mine. They will have to get over it. > > Okay, so you are just one of those ignorant assholes who drive people > away from projects because they think their are the middle of the > universe and other problems don't exist because they have never > experienced them and oh deity forbid if someone insults their holy > grammarbooks and linguists. Cool. Glad that we have solved that. > > That's actually the first time that I'm not polite. But I can't be > polite to ignorant people. I just won't work with you anymore and ignore > you, as you choose to ignore other people with your behavior and > invalidate their existence and bother them with your view of what's > "correct" and what's not. This reaction is highly intolerant and not acceptable in this community. Disagreeing doesn't justify being rude or insulting people. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: grammar usage
Hello Ricardo, Ricardo Wurmus writes: > Andy Wingo writes: > > […] > >> I understand you feel this way, however to others the effect is >> important. To trans and non-binary people, being at the receiving end >> of a stream of misgenderings (intentional or not) is a constant >> irritation, reminding them that they are not welcome in that part of the >> world. We want Guix to be welcoming to everyone, so we should be >> attentive to hints about what pronoun people would like others to use >> when referring to them. >> >>> Why is it only advocacy of *my* opinion which is unwelcome whereas >>> that of others is perfectly acceptable? I feel that I am being >>> victimised here. >> >> To create a welcoming environment for more people and especially people >> who are marginalized, we must make some behaviors unwelcome. In this >> case, advocating this opinion of what is correct English contributes to >> the marginalization of trans and non-binary people, and for that reason >> I think it is appropriate for the Guix project to discourage this >> behavior in its spaces. > > Thank you, Andy. I agree with everything you wrote, in particular how > this relates to our goal of creating a welcoming environment, which is a > main task for maintainers. Could you tell us what this maintainer task consist of? Thanks. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Using cuirass to build your own manifest.
Hi, Mathieu Othacehe writes: > Here's a small tutorial on how to setup cuirass to build your own > manifest. Amazing work! :) > I see two major reasons for this kind of setup: > > * When you pull latest guix, hydra and bayfront may not have finished > building all the packages you use. > > * Hydra and bayfront won't build your custom packages. This is definitely a use case that I expect to be common so I agree with Ludo that would make sense to make a service for that. > To finish, the downsides of this setup are : > * You need to keep your manifest up-to-date on your build machine. Do you have ideas/suggestions on how to improve that? > * There are no easy ways to track cuirass status but to do some sql on > cuirass database. With the HTTP API that I hope will be implemented this summer, the situation would hopefully be better. Thank you for this tutorial. This is really useful given the current state of Cuirass documentation. ;) -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: [GSoC] Development of Cuirass.
Hello Florian, "pelzflorian (Florian Pelz)" writes: > On 03/12/2017 03:49 PM, Mathieu Lirzin wrote: >> Sensitive requests should be done with an >> authentification mechanism which is not determined yet. I currently >> have no experience with any and lack the knowledge to properly choose >> one. > > I’m new to Guix and Scheme and no expert in Web programming, but in > order to prevent CSRF and in order not to rely on JavaScript, the server > should run with HTTPS (of course) and > · use a secret session token and > · send a customized Web page to the client adapted so that each link and > form to the server includes the session token as a GET or POST parameter. > > An alternative is Basic Access Authentication with HTTPS or Cookies with > HTTPS but they are vulnerable to CSRF. > > See stackoverflow, for example > > https://stackoverflow.com/questions/21357182/csrf-token-necessary-when-using-stateless-sessionless-authentication Thanks for your input. Have you any experience/advice regarding OAuth or Json Web Token (JWT) ? -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
[GSoC] Development of Cuirass.
Hi, Here is my proposal for the Google Summer of Code 2017. 1 Introduction ══ [Cuirass] is a build automation server using GNU Guix package manager. This project has started last year as a Google Summer of Code (GSoC) with the goal of replacing [Hydra] which is the continous build server used by Nix and Guix to provide package substitutes. Cuirass intends to be a multi-purpose build automation server. It aims at allowing users to have their own build farm for packages they maintain outside of Guix tree, and at providing a tool for applying the principle of continuous integration[1] in software development. To achieve this goal a lot of things remain to be done. [Cuirass] https://notabug.org/mthl/cuirass [Hydra] https://nixos.org/hydra/ 2 Proposal ══ The project is the continuation of last year work, and is separated in two parts. The first part is to improve the testing infrastructure. The second one is about providing a more complete HTTP API. 2.1 The testing infrastructure ── Currently Cuirass is providing a small test suite consisting only of unit tests. The integration tests are done manually with basic examples consisting in building small packages such as GNU Hello. This is not good, because actual packages take a consequent time to compile, and testing only basic examples leaves the interesting complex case out of the scope of testing. The worst is that the result depend on the phase of the moon since every commit in Guix can potentially break the build. The idea is to take inspiration from the Guix test suite by providing tiny mocked packages that will help having lightweight build specifications. Those tests require launching another instance of the `guix-daemon' with a local temporary store. 2.2 HTTP API Since commit [12d71ee098c3eb84a9a5dc2419bd37a3b9e55dd2] Cuirass has a web server which is running in a separate thread of the `cuirass' process. However the resources it provides are pretty limited since you can only query the lists of specifications currently watched. This is done with the `/specifications' or `/jobsets' resource names. "Jobsets" is the terminology used by Hydra and is used here for compatibility with its HTTP API. The principal objective of this part is to provide a more complete API which allows users to query the build results and to add their specifications to the current set. The design of this API will apply the principles of the Representational State Transfert (REST) architectural pattern[2]. Sensitive requests should be done with an authentification mechanism which is not determined yet. I currently have no experience with any and lack the knowledge to properly choose one. [12d71ee098c3eb84a9a5dc2419bd37a3b9e55dd2] https://notabug.org/mthl/cuirass/commit/12d71ee098c3eb84a9a5dc2419bd37a3b9e55dd2 3 Roadmap ═ This roadmap lacks details about the concrete tasks and its associated timeline. However I prefer having some feedback about this proposal first, before providing a complete roadmap. • From May 30 to June 26, I will work on the testing infrastructure,. • From June 27 to August 29, I will work on the HTTP API. 4 Feedback ══ Some people have expressed their interest in having a Web /frontend/ for Cuirass. To avoid possible confusions I have no plan in working on it this summer. While this would be a very valuable effort, I don't feel up to the task. Regarding the Authentification mechanism, any enlighten advice or resource would be welcome. If anybody think of other important tasks that need to be addressed, please share. Footnotes ─ [1] [https://martinfowler.com/articles/continuousIntegration.html] [2] [https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm] -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: [PATCH 1/2] build: Use an up to date copy of texinfo.tex
John Darrington writes:
> On Fri, Feb 24, 2017 at 08:25:20PM +0100, Mathieu Lirzin wrote:
>
> John Darrington writes:
>
> > * build-aux/texinfo.tex,ref: New file, copied from texlive-minimal
> > * bootstrap: Use it, if newer than the texinfo.tex from automake.
> > ---
> > bootstrap |11 +-
> > build-aux/texinfo.tex,ref | 11562
>
> > 2 files changed, 11572 insertions(+), 1 deletion(-)
> > create mode 100644 build-aux/texinfo.tex,ref
> >
>
> Do you know why building Guix manual fails to build with older
> "texinfo.tex"?
>
> If this related to some special texinfo syntax used in Guix manual?
>
> Yes. It's the use of @inlinefmtifelse command. (perhaps other commands too).
There is only one instance of this command which is in "doc/guix.texi":
If you are instead planning to encrypt the root partition, you can use
the Cryptsetup/LUKS utilities to do that (see @inlinefmtifelse{html,
@uref{https://linux.die.net/man/8/cryptsetup, @code{man cryptsetup}},
@code{man cryptsetup}} for more information.)
I have tested that without it, 'make pdf' succeeds. IMHO the manual
would be fine without this feature. As a consequence --to avoid adding
complexity to the build process-- I would be in favour of not using
@inlinefmtifelse until Automake distributes a compatible version in its
current version.
> What about checking in texinfo.tex and removing the -f (--force) option
> when invoking 'autoreconf'? This would ensure that texinfo.tex is not
> overwritten.
>
>
> I guess it might work. But I haven't tried it.
Thank you for the debugging information. :)
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: [PATCH 1/2] build: Use an up to date copy of texinfo.tex
Hello John, John Darrington writes: > * build-aux/texinfo.tex,ref: New file, copied from texlive-minimal > * bootstrap: Use it, if newer than the texinfo.tex from automake. > --- > bootstrap |11 +- > build-aux/texinfo.tex,ref | 11562 > > 2 files changed, 11572 insertions(+), 1 deletion(-) > create mode 100644 build-aux/texinfo.tex,ref > Do you know why building Guix manual fails to build with older "texinfo.tex"? If this related to some special texinfo syntax used in Guix manual? > diff --git a/bootstrap b/bootstrap > index cb774bc73..052c433a0 100755 > --- a/bootstrap > +++ b/bootstrap > @@ -2,4 +2,13 @@ > # Create the build system. > > set -e -x > -exec autoreconf -vfi > +ref=$(grep '\\def\\texinfoversion' build-aux/texinfo.tex,ref | tr -c -d > [:digit:]) > +autoreconf -vfi > +ac=$(grep '\\def\\texinfoversion' build-aux/texinfo.tex | tr -c -d [:digit:]) > + > +# Use our reference version of texinfo.tex or the one from automake, > whichever > +# is most recent. > +if [ $ref -gt $ac ] ; then > +cp -f build-aux/texinfo.tex,ref build-aux/texinfo.tex; > +fi What about checking in texinfo.tex and removing the -f (--force) option when invoking 'autoreconf'? This would ensure that texinfo.tex is not overwritten. WDYT? Thanks. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: [PATCH 0/1] improvements to the lightweight desktop example
John Darrington writes: > On Wed, Feb 22, 2017 at 04:48:55PM +0100, Mathieu Lirzin wrote: > > Sure it is! > > What I meant is that Ratpoison is not the most "intuitive" WM for non > GNU Emacs/Screen users. As a consequence adding it in an example > configuration which is likely to be copy and paste, is maybe not the > most welcoming thing. :) > > IMHO Openbox or anything which is able to launch a program by "clicking" > seems more friendly as a default (modulo the accessibility issues which > to my knowledge are not addressed by any of the "lightweight" WMs). > ... > So most of them found "clicking" extremely unfriendly. Please be very > carefull when making generalisations like "GUIs are intuitive" "mice are > friendly" etc. As we said before - it depends uponn the user. I don't think I have made this generalisation. :) I haven't said that "clicking is more friendly". I have precisely said "'clicking' seems more friendly as a default". "defaults" are not adapted to everybody, especially in the case of people who are computer illiterates. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Leaving the guix project
Leo Famulari writes: > Please, everyone, can we try to keep this discussion civil? > > The fact that we all find ourself on this mailing list makes me think > that we all care about free software in some way or another. > > It's true that within that broad idea we have different values and > preferences, but I think we should be more generous when interpreting > each others' messages. For christ sake, love you each other! :) Joke aside, I agree with you Leo. I agree with Pjotr too, I think it is time to drop this thread. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: [PATCH 0/1] improvements to the lightweight desktop example
Hello Clément, Clément Lassieur writes: > Mathieu Lirzin writes: > >> While we are on this lightweight template, what would you think of >> replacing ratpoison with something less "exotic" like openbox? :) > > What do you mean by "exotic"? Isn't that subjective? :) Sure it is! What I meant is that Ratpoison is not the most "intuitive" WM for non GNU Emacs/Screen users. As a consequence adding it in an example configuration which is likely to be copy and paste, is maybe not the most welcoming thing. :) IMHO Openbox or anything which is able to launch a program by "clicking" seems more friendly as a default (modulo the accessibility issues which to my knowledge are not addressed by any of the "lightweight" WMs). > Here are the results of "guix size": > - ratpoison: 172.6 MiB, > - i3-wm: 263.4 MiB, > - openbox: 322.9 MiB. > > So Openbox is almost twice as big as Ratpoison, which I think matters > for a "lightweight" template. Furthermore, Ratpoison quite is > convenient to use for those of us who use GNU Emacs and GNU Screen. As a former dedicated user of Ratpoison, I know and appreciate all its niceness. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: [PATCH 0/1] improvements to the lightweight desktop example
Hi, Leo Famulari writes: > I think we should remove xmonad from the lightweight-desktop OS > declaration example. Xmonad is not "lightweight" in terms of disk space > or bandwidth, since it requires GHC, which is 859 MiB uncompressed. Makes sense. > Also, the i3 window manager is not very useful without dmenu and > i3status, so I think we should add them. Agreed. While we are on this lightweight template, what would you think of replacing ratpoison with something less "exotic" like openbox? :) > Leo Famulari (1): > gnu: lightweight-desktop.tmpl: Remove xmonad and complete i3-wm. > > gnu/system/examples/lightweight-desktop.tmpl | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: RFC: writable private scratch XDG_CACHE_HOME in build enviroment?
Andy Wingo writes: > On Tue 21 Feb 2017 13:13, Mathieu Lirzin writes: > >> IIUC the problem you have is that in a Guix build environmnent, Guile >> tries but *fails* to autocompile ".scm" files because it doesn't find >> any directory that it can write on? > > Correct. > >> Since /tmp is writeable in a Guix build environment and in most POSIX >> systems (I guess), Would it make sense for Guile itself to fallback to >> /tmp for its compilation cache? > > It's possible. It's a bit gnarly though: > > * you get the usual race conditions between users and /tmp that you > have to mitigate Nothing different from the race conditions for a single user using XDG_CACHE_HOME when compilation is done by multiple threads? > * you have to be more careful about permissions (it could be that the > .go embeds something secret) > - each user would have to have their own path here Indeed. > * guile would have to look in /tmp in addition to XDG_CACHE_HOME when > looking for autocompiled files > > * what if the one in /tmp is fresh but the one in XDG_CACHE_HOME is > not, or vice versa? This two last points makes me think of a the general issue with caching. Maybe we could apply the the sane principles of memoization by computing the "value" of a file (by hashing it?) and search it in the different ".go" stores (GUILE_LOAD_COMPILED_PATH, XDG_CACHE_HOME, site-ccache, ...)? I don't know if the idea is stupid or not, maybe I miss an obvious point. Anyway this doesn't fit the purpose of fixing your issue in the short term. > I'd rather use XDG_CACHE_HOME for this as it's already well specified > and actually not Guile-specific > (https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html). Setting XDG_CACHE_HOME to the build directory or /tmp in the Guix build environnement seems fine to me. Thanks. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: RFC: writable private scratch XDG_CACHE_HOME in build enviroment?
Hello Andy,
Andy Wingo writes:
> Guile will try to automatically compile .scm files and cache them in
> XDG_CACHE_HOME. When building Guile itself, Guile sets XDG_CACHE_HOME
> to ${top_builddir}/cache. What if we would set this ourselves for all
> packages? That way all packages could benefit from a scratch location
> when building that wouldn't propagate to the outputs.
>
> In Fibers I have some tests that I assume get compiled. If they're not
> compiled, they go quite slow (260s vs 5s). Alternately I could add a
> XDG_CACHE_HOME setting in Fibers. Which should we do?
IIUC the problem you have is that in a Guix build environmnent, Guile
tries but *fails* to autocompile ".scm" files because it doesn't find
any directory that it can write on?
Even if I would not recommend relying on autocompilation in a build
process (or anywhere else) I agree that it would be reasonable to have a
way to autocompile ".scm" files in a Guix build environment.
Since /tmp is writeable in a Guix build environment and in most POSIX
systems (I guess), Would it make sense for Guile itself to fallback to
/tmp for its compilation cache?
Thanks.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Add a generalized git-file? to Guix?
Christopher Allan Webber writes: > Ludovic Courtès writes: > >> Mathieu Lirzin skribis: >> >>> From f104b3745097746d6ef89b6198ec7b81e8b679f4 Mon Sep 17 00:00:00 2001 >>> From: Mathieu Lirzin >>> Date: Sun, 29 Jan 2017 00:34:48 +0100 >>> Subject: [PATCH] git-download: Add 'git-predicate'. >>> >>> * guix/git-download.scm (git-predicate): New procedure. >>> * gnu/packages/package-management.scm (current-guix): Use it. >>> (make-git-predicate): Remove. >> >> LGTM, thanks! >> >> Ludo'. > > I just pushed this. Switching my various projects over to using it now. > Thank you for doing the work to abstract it out Mathieu! Thank you for pushing it. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: [PATCH] maint: Fix invalid calls to 'info'.
l...@gnu.org (Ludovic Courtès) writes: > Mathieu Lirzin skribis: > >> * HACKING : Remove name of the manual from the item argument. >> * README : Likewise. > > Good catch, please push! > > Ludo’. Pushed as commit 8efc35a8902910ef7c09183c1d79d51498b2c10c. Thanks. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
[PATCH] maint: Fix invalid calls to 'info'.
* HACKING : Remove name of the manual from the item argument. * README : Likewise. --- Hi, On Debian testing, with info (GNU texinfo) 6.3 the documented calls to info don't work: $ info -f doc/guix.info "(guix) Contributing" info: No menu item '(guix) Contributing' in node '(guix.info)Top'. HACKING | 4 ++-- README | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/HACKING b/HACKING index e210143c9..1e0bddfaf 100644 --- a/HACKING +++ b/HACKING @@ -3,7 +3,7 @@ #+TITLE: Hacking GNU Guix and Its Incredible Distro Copyright © 2012, 2013, 2014, 2016 Ludovic Courtès -Copyright © 2015 Mathieu Lirzin +Copyright © 2015, 2017 Mathieu Lirzin Copyright © 2017 Leo Famulari Copying and distribution of this file, with or without modification, @@ -14,7 +14,7 @@ Copyright © 2017 Leo Famulari See the manual for useful hacking informations, either by running - info -f doc/guix.info "(guix) Contributing" + info -f doc/guix.info "Contributing" or by checking the [[http://www.gnu.org/software/guix/manual/guix.html#Contributing][web copy of the manual]]. diff --git a/README b/README index f05a4b561..5829320dc 100644 --- a/README +++ b/README @@ -42,7 +42,7 @@ When `--disable-daemon' was passed, you instead need the following: See the manual for the installation instructions, either by running - info -f doc/guix.info "(guix) Installation" + info -f doc/guix.info "Installation" or by checking the [[http://www.gnu.org/software/guix/manual/guix.html#Installation][web copy of the manual]]. -- 2.11.0
[PATCH] gnu packages: Add 'specifications->inputs'.
* gnu/packages.scm (specifications->inputs): New procedure. --- Hi, Using 'specification->package' is not convenient for package inputs in 'guix.scm' development packages because it involves either using it over and over or defining a custom procedure. I think it would be nice if Guix was providing a concise way to achieve the desired result. This patch is an attempt to fix that inconvenience. Thanks. Mathieu gnu/packages.scm | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/gnu/packages.scm b/gnu/packages.scm index 0aa289d56..8b47ed83f 100644 --- a/gnu/packages.scm +++ b/gnu/packages.scm @@ -3,7 +3,7 @@ ;;; Copyright © 2013 Mark H Weaver ;;; Copyright © 2014 Eric Bavier ;;; Copyright © 2016 Alex Kost -;;; Copyright © 2016 Mathieu Lirzin +;;; Copyright © 2016, 2017 Mathieu Lirzin ;;; ;;; This file is part of GNU Guix. ;;; @@ -53,7 +53,8 @@ find-newest-available-packages specification->package -specification->package+output)) +specification->package+output +specifications->inputs)) ;;; Commentary: ;;; @@ -356,3 +357,14 @@ version; if SPEC does not specify an output, return OUTPUT." (leave (_ "package `~a' lacks output `~a'~%") (package-full-name package) sub-drv)) + +(define (specifications->inputs specs) + "Return an alist that can be used in package definition. This alist is +composed of entries of type '(KEY . (PACKAGE OUTPUT))' where KEY is an element +from SPECS, PACKAGE is its associated package, and OUTPUT is its associated +output." + (map (lambda (spec) + (let-values (((package output) + (specification->package+output spec))) + (list spec package output))) + specs)) -- 2.11.0
Re: Add a generalized git-file? to Guix?
Hello,
l...@gnu.org (Ludovic Courtès) writes:
> Mathieu Lirzin skribis:
>
>> Christopher Allan Webber writes:
>>
>>> 8sync now uses `git-file?' in its guix.scm, a predicate check which
>>> allows for checking out the whole local directory as a "source" for
>>> testing a package. I borrowed it from Dave who originally adapted
>>> it from some code in Guix itself. See:
>>>
>>> http://git.savannah.gnu.org/cgit/8sync.git/tree/guix.scm#n62
>>>
>>> This is pretty handy; probably other projects would like to make use of
>>> it. What do we think of making it a generally available utility?
>>
>> I would make use of it and I am in favour of adding it to Guix.
>
> I think it comes from ‘current-guix’ in package-management.scm, and yes,
> we should probably make it public.
>
> Would someone like to submit a patch? The most difficult issue is
> finding in file in which to store it. ;-) Maybe git-download.scm?
Here is a patch renaming 'make-git-predicate' to 'git-predicate' and
moving it to (guix git-download).
>From f104b3745097746d6ef89b6198ec7b81e8b679f4 Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin
Date: Sun, 29 Jan 2017 00:34:48 +0100
Subject: [PATCH] git-download: Add 'git-predicate'.
* guix/git-download.scm (git-predicate): New procedure.
* gnu/packages/package-management.scm (current-guix): Use it.
(make-git-predicate): Remove.
---
gnu/packages/package-management.scm | 37 +--
guix/git-download.scm | 43 -
2 files changed, 43 insertions(+), 37 deletions(-)
diff --git a/gnu/packages/package-management.scm b/gnu/packages/package-management.scm
index 92787d76c..272fc6ab0 100644
--- a/gnu/packages/package-management.scm
+++ b/gnu/packages/package-management.scm
@@ -25,7 +25,6 @@
#:use-module (guix utils)
#:use-module (guix build-system gnu)
#:use-module (guix build-system python)
- #:use-module ((guix build utils) #:select (with-directory-excursion))
#:use-module ((guix licenses) #:select (gpl2+ gpl3+ lgpl2.1+ asl2.0))
#:use-module (gnu packages)
#:use-module (gnu packages guile)
@@ -53,10 +52,6 @@
#:use-module (gnu packages tls)
#:use-module (gnu packages ssh)
#:use-module (gnu packages vim)
- #:use-module (srfi srfi-1)
- #:use-module (srfi srfi-26)
- #:use-module (ice-9 popen)
- #:use-module (ice-9 rdelim)
#:use-module (ice-9 match))
(define (boot-guile-uri arch)
@@ -275,38 +270,8 @@ generated file."
(_
#t)))
-(define (make-git-predicate directory)
- "Return a predicate that returns true if a file is part of the Git checkout
-living at DIRECTORY. Upon Git failure, return #f instead of a predicate."
- (define (parent-directory? thing directory)
-;; Return #t if DIRECTORY is the parent of THING.
-(or (string-suffix? thing directory)
-(and (string-index thing #\/)
- (parent-directory? (dirname thing) directory
-
- (let* ((pipe(with-directory-excursion directory
-(open-pipe* OPEN_READ "git" "ls-files")))
- (files (let loop ((lines '()))
-(match (read-line pipe)
- ((? eof-object?)
- (reverse lines))
- (line
- (loop (cons line lines))
- (status (close-pipe pipe)))
-(and (zero? status)
- (lambda (file stat)
- (match (stat:type stat)
- ('directory
- ;; 'git ls-files' does not list directories, only regular files,
- ;; so we need this special trick.
- (any (cut parent-directory? <> file) files))
- ((or 'regular 'symlink)
- (any (cut string-suffix? <> file) files))
- (_
- #f))
-
(define-public current-guix
- (let ((select? (delay (or (make-git-predicate
+ (let ((select? (delay (or (git-predicate
(string-append (current-source-directory)
"/../.."))
source-file?
diff --git a/guix/git-download.scm b/guix/git-download.scm
index 62e625c71..5d86ab2b6 100644
--- a/guix/git-download.scm
+++ b/guix/git-download.scm
@@ -1,5 +1,6 @@
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2014, 2015, 2016 Ludovic Courtès
+;;; Copyright © 2017 Mathieu Lirzin
;;;
;;; This file is part of GNU Guix.
;;;
@@ -17,6 +18,7 @@
;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
(define-module (guix git-download)
+ #:use-module (guix build utils)
#:use-module (guix gexp)
#:use-module (guix store)
#:use-module (guix monads)
@@ -
Re: [PATCH] gnu: Add GNU Freetalk.
Hello,
Clément Lassieur writes:
> * gnu/packages/messaging.scm (freetalk): New variable.
> ---
> gnu/packages/messaging.scm | 56
> +-
> 1 file changed, 55 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/packages/messaging.scm b/gnu/packages/messaging.scm
> index 5b3ed740d..91df75aea 100644
> --- a/gnu/packages/messaging.scm
> +++ b/gnu/packages/messaging.scm
> @@ -78,7 +78,12 @@
>#:use-module (gnu packages xiph)
>#:use-module (gnu packages audio)
>#:use-module (gnu packages bison)
> - #:use-module (gnu packages fontutils))
> + #:use-module (gnu packages fontutils)
> + #:use-module (gnu packages bash)
> + #:use-module (gnu packages guile)
> + #:use-module (gnu packages less)
> + #:use-module (gnu packages readline)
> + #:use-module (gnu packages texinfo))
>
> (define-public libotr
>(package
> @@ -1188,4 +1193,53 @@ support, and more.")
> (synopsis "Small XMPP console client")
> (license license:gpl2+)))
>
> +(define-public freetalk
> + (package
> +(name "freetalk")
> +(version "4.1")
> +(source
> + (origin
> + (method url-fetch)
> + (uri (string-append "mirror://gnu/freetalk/freetalk-" version
> ".tar.gz"))
> + (sha256
> +(base32 "1rmrn7a1bb7vm26yaklrvx008a9qhwc32s57dwrlf40lv9gffwny"
> +(build-system gnu-build-system)
> +(arguments
> + `(#:phases
> + (modify-phases %standard-phases
> + (add-before 'configure 'autogen
> + (lambda _
> + (zero? (system* "sh" "autogen.sh"
> + ;; For 'system' commands in Scheme code.
> + (add-after 'install 'wrap-program
> + (lambda* (#:key inputs outputs #:allow-other-keys)
> + (let* ((out (assoc-ref outputs "out"))
> +(bash (assoc-ref inputs "bash"))
> +(coreutils (assoc-ref inputs "coreutils"))
> +(less (assoc-ref inputs "less")))
> + (wrap-program (string-append out "/bin/freetalk")
> + `("PATH" ":" prefix
> + ,(map (lambda (dir)
> + (string-append dir "/bin"))
> + (list bash coreutils less))
^^^
I have made it return #t.
> +(native-inputs
> + `(("autoconf" ,autoconf)
> + ("automake" ,automake)
> + ("texinfo" ,texinfo)
> + ("pkg-config" ,pkg-config)))
> +(inputs
> + `(("bash" ,bash)
> + ("glib" ,glib)
> + ("guile" ,guile-2.0)
> + ("less" ,less)
> + ("loudmouth" ,loudmouth)
> + ("readline" ,readline)))
> +(synopsis "Extensible console-based Jabber/XMPP client")
I have used the synopsis suggested by 'guix lint'.
> +(description "GNU Freetalk is a command-line Jabber/XMPP chat client. It
> +notably uses the Readline library to handle input, so it features convenient
> +navigation of text as well as tab-completion of buddy names, commands and
> +English words. It is also scriptable and extensible via Guile.")
> +(home-page "https://www.gnu.org/software/freetalk/freetalk.html";)
> +(license license:gpl3+)))
> +
> ;;; messaging.scm ends here
Pushed with those minor changes as commit
c631233fd44fe6ea32197fa21fda35fc864d0d2a.
Thank you!
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Build custom packages with cuirass.
Hi, Mathieu OTHACEHE writes: > Using cuirass I also noticed two other things that might need to be fixed: > > * When network isn't up yet at cuirass service start, > or goes down for a moment, the url fetching > fails and cuirass service stays hanged and needs to be restarted. > > * For an unknown reason, I have random freezes of cuirass, the polling > stops and nothing is outputed to log. I'm stracing it to find out why > ... I have created 2 separate issues on Notabug Web interface to track those bugs: https://notabug.org/mthl/cuirass/issues Thanks for reporting them. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Build custom packages with cuirass.
Hi, Mathieu OTHACEHE writes: > I'm trying to use cuirass to build all the packages of my current > manifest on top of guix master periodically. > > Some of my packages are custom, so I need cuirass to be aware of > GUIX_PACKAGE_PATH env variable. > > The only way I found is to patch cuirass service (cf. following patch). > Is this a good idea ? Is someone doing this kind of stuff here ? A quick and dirty way to fix your issue would be to add the absolute base directory name for your custom package modules in the '#:load-path' part of you specification. However this will only work if your modules names are '(gnu packages ...)'. I guess Cuirass should handle this use case with '-L', '--load-path' command line arguments like what 'guix build' does. WDYT? Would you be interested in implementing this? Thanks. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: [PATCH v2] services: cuirass: Add port to cuirass configuration
Hello, Mathieu Othacehe writes: > * gnu/services/cuirass.scm (): Add port field. > (cuirass-shepherd-service): Honor it. > * doc/guix.texi (Continuous Integration): Document it. > --- Applied as 11b7717deba42b1f8286158e1cf4b58dec533859. Thank you. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Ideas for Summer of Code 2017
Hello, GNU is applying as an organization for Google Summer of Code 2017. So this is time to start gathering ideas for possible Guix/Shepherd related projects. I have created a page based on the one from last year: https://libreplanet.org/wiki/Group:Guix/GSoC-2017 It's a Wiki, so feel free to contribute to it. TIA. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: [PATCH] git download: Remove redundant argument in 'gexp->derivation' call.
l...@gnu.org (Ludovic Courtès) writes: > Mathieu Lirzin skribis: > >> * guix/git-download.scm (git-fetch): Call 'gexp->derivation' with only one >> '#:local-build?' keyword argument. > > Good catch! Thanks, > Ludo'. Pushed in commit 5c6a30c5119ffd5702c02e07e7f04669a8f225bb. Thanks. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: [PATCH] derivations: Make record datatype immutable.
l...@gnu.org (Ludovic Courtès) writes: > Mathieu Lirzin skribis: > >> * guix/derivations.scm (): Make it immutable. >> (derivation): Use generic 'set-field' instead of ad-hoc functional setter. > > LGTM, thanks! > > Ludo'. Pushed in commit dc673fa1131fb5d1e5ca29acb4a693cfb906986f. Thanks. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Add a generalized git-file? to Guix?
Hi, Christopher Allan Webber writes: > Thompson, David writes: > >> Hi Christopher and Jan, >> >> On Tue, Jan 10, 2017 at 11:28 AM, Christopher Allan Webber >> wrote: >>> Jan Nieuwenhuizen writes: >>> >>>> Christopher Allan Webber writes: >>>> >>>>> Thanks! >>>>> >>>>> The file is updated, and even nicer now, since I'm using a hack from >>>>> guile-sdl2 which allows you to set the source to the whole checkout. >>>> >>>> Ohh! That needs to go in the Guix manual... could git-file? be added >>>> to guix/utils? >>> >>> Maybe! I think David knows more about the provenance? >> >> I took this code from Ludovic. See make-git-predicate in >> gnu/packages/package-management.scm in the Guix source tree. >> >>> I agree it would be nice to have in Guix itself. >> >> Agreed. A generalized and publicly available procedure would be great. >> >> - Dave > > Hello! See the above conversation... 8sync now uses `git-file?' in its > guix.scm, a predicate check which allows for checking out the whole > local directory as a "source" for testing a package. I borrowed it from > Dave who originally adapted it from some code in Guix itself. See: > > http://git.savannah.gnu.org/cgit/8sync.git/tree/guix.scm#n62 > > This is pretty handy; probably other projects would like to make use of > it. What do we think of making it a generally available utility? I would make use of it and I am in favour of adding it to Guix. Thanks. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
[PATCH] git download: Remove redundant argument in 'gexp->derivation' call.
* guix/git-download.scm (git-fetch): Call 'gexp->derivation' with only one '#:local-build?' keyword argument. --- guix/git-download.scm | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/guix/git-download.scm b/guix/git-download.scm index fca44f552..62e625c71 100644 --- a/guix/git-download.scm +++ b/guix/git-download.scm @@ -109,8 +109,7 @@ HASH-ALGO (a symbol). Use NAME as the file name, or a generic name if #f." #:hash-algo hash-algo #:hash hash #:recursive? #t - #:guile-for-build guile - #:local-build? #t))) + #:guile-for-build guile))) (define (git-version version revision commit) "Return the version string for packages using git-download." -- 2.11.0
[PATCH] derivations: Make record datatype immutable.
* guix/derivations.scm (): Make it immutable. (derivation): Use generic 'set-field' instead of ad-hoc functional setter. --- guix/derivations.scm | 17 + 1 file changed, 5 insertions(+), 12 deletions(-) diff --git a/guix/derivations.scm b/guix/derivations.scm index d5e4b5730..b712c508e 100644 --- a/guix/derivations.scm +++ b/guix/derivations.scm @@ -1,5 +1,6 @@ ;;; GNU Guix --- Functional package management for GNU ;;; Copyright © 2012, 2013, 2014, 2015, 2016, 2017 Ludovic Courtès +;;; Copyright © 2016, 2017 Mathieu Lirzin ;;; ;;; This file is part of GNU Guix. ;;; @@ -120,7 +121,7 @@ ;;; Nix derivations, as implemented in Nix's `derivations.cc'. ;;; -(define-record-type +(define-immutable-record-type (make-derivation outputs inputs sources system builder args env-vars file-name) derivation? @@ -817,14 +818,6 @@ output should not be used." e outputs))) - (define (set-file-name drv file) -;; Set FILE as the 'file-name' field of DRV. -(match drv - (($ outputs inputs sources system builder - args env-vars) - (make-derivation outputs inputs sources system builder -args env-vars file - (define input->derivation-input (match-lambda (((? derivation? drv)) @@ -872,9 +865,9 @@ output should not be used." (let* ((file (add-text-to-store store (string-append name ".drv") (derivation->string drv) (map derivation-input-path inputs))) - (drv (set-file-name drv file))) - (hash-set! %derivation-cache file drv) - drv))) + (drv* (set-field drv (derivation-file-name) file))) + (hash-set! %derivation-cache file drv*) + drv*))) (define* (map-derivation store drv mapping #:key (system (%current-system))) -- 2.11.0
Re: Cuirass and duplicate derivations
Mathieu Lirzin writes:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> What change would you suggest to solve this problem? It would be best
>> if Cuirass allowed several jobs building the same derivations (the key
>> could be an autoincrement counter instead of the (drv,eval) pair maybe?)
>
> Seems reasonable to me. I will do that.
> Thanks.
After a second thought, I think maybe it is sufficient to just ignore
when a derivation is added twice by an evaluation. As a consequence
'cuirass' will only try to realize the derivation once per evaluation.
>From 568d0e1b0866a45e95440d17b6e8f1740cc23e3f Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin
Date: Mon, 9 Jan 2017 01:29:48 +0100
Subject: [PATCH] database: db-add-derivation: Don't try to add a derivation
twice.
* src/cuirass/database.scm (db-add-derivation): Ignore if JOB is already
present in DB.
---
src/cuirass/database.scm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/cuirass/database.scm b/src/cuirass/database.scm
index 870cdc0..702e643 100644
--- a/src/cuirass/database.scm
+++ b/src/cuirass/database.scm
@@ -147,7 +147,7 @@ INSERT OR IGNORE INTO Specifications (repo_name, url, load_path, file, \
(define (db-add-derivation db job)
"Store a derivation result in database DB and return its ID."
(sqlite-exec db "\
-INSERT INTO Derivations (derivation, job_name, evaluation)\
+INSERT OR IGNORE INTO Derivations (derivation, job_name, evaluation)\
VALUES ('~A', '~A', '~A');"
(assq-ref job #:derivation)
(assq-ref job #:job-name)
--
2.11.0
WDYT?
Thanks.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Cuirass and duplicate derivations
Hello,
l...@gnu.org (Ludovic Courtès) writes:
> Cuirass is almost up and running on the new machine! :-)
Great work!
> The last problem I experienced is this:
>
> evaluate 'gfortran-4.9.4.x86_64-linux': 0.136 seconds
> evaluate 'gfortran-4.9.4.x86_64-linux': 0.000 seconds
> Backtrace:
> In ice-9/boot-9.scm:
> 160: 12 [catch #t # ...]
> In unknown file:
>?: 11 [apply-smob/1 #]
> In ice-9/boot-9.scm:
> 66: 10 [call-with-prompt prompt0 ...]
> In ice-9/eval.scm:
> 432: 9 [eval # #]
> In ice-9/r4rs.scm:
> 90: 8 [dynamic-wind # ...]
> In ice-9/eval.scm:
> 481: 7 [lp (# #) ("/var/run/cuirass/cuirass.db" #f)]
> 481: 6 [lp (#) (#f)]
> 432: 5 [eval # #]
> 387: 4 [eval # #]
> In ice-9/boot-9.scm:
> 705: 3 [map # #]
> In ice-9/eval.scm:
> 432: 2 [eval # #]
> In src/cuirass/database.scm:
> 54: 1 [sqlite-exec # ...]
> In ice-9/eval.scm:
> 432: 0 [eval # #]
>
> ice-9/eval.scm:432:17: In procedure eval:
> ice-9/eval.scm:432:17: Throw to key `sqlite-error' with args `(#f 1555
> "UNIQUE constraint failed: Derivations.derivation, Derivations.evaluation")'.
>
> … which commit 7355634db3ccf0d86f8e34c4aea37392c1a0ab0a fixes.
>
> Then there was another one:
>
> evaluate 'wine-1.9.24.i686-linux': 0.205 seconds
> Backtrace:
> In ice-9/boot-9.scm:
> 160: 12 [catch #t # ...]
> In unknown file:
>?: 11 [apply-smob/1 #]
> In ice-9/boot-9.scm:
> 66: 10 [call-with-prompt prompt0 ...]
> In ice-9/eval.scm:
> 432: 9 [eval # #]
> In ice-9/r4rs.scm:
> 90: 8 [dynamic-wind # ...]
> In ice-9/eval.scm:
> 481: 7 [lp (# #) ("/var/run/cuirass/cuirass.db" #f)]
> 481: 6 [lp (#) (#f)]
> 432: 5 [eval # #]
> 387: 4 [eval # #]
> In ice-9/boot-9.scm:
> 703: 3 [map # #]
> In ice-9/eval.scm:
> 432: 2 [eval # #]
> In src/cuirass/database.scm:
> 54: 1 [sqlite-exec # ...]
> In ice-9/eval.scm:
> 432: 0 [eval # #]
>
> ice-9/eval.scm:432:17: In procedure eval:
> ice-9/eval.scm:432:17: Throw to key `sqlite-error' with args `(#f 1555
> "UNIQUE constraint failed: Derivations.derivation, Derivations.evaluation")'.
>
> This is because Wine is always built for i686-linux, even on x86_64,
> hence the same .drv. So I hacked my way to ignore Wine.
>
> But then ‘cargo-bootstrap’ showed the same problem.
>
> Hence this message. :-)
>
> What change would you suggest to solve this problem? It would be best
> if Cuirass allowed several jobs building the same derivations (the key
> could be an autoincrement counter instead of the (drv,eval) pair maybe?)
Seems reasonable to me. I will do that.
Thanks.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Graphical GuixSD Installer
Hi John, John Darrington writes: > There is a new branch called "wip-installer" providing a graphical > installer for GuixSD. A screenshot of it in action is attached. > > We want GuixSD to be accessible to as many people as possible, > including people who may not (yet) be comfortable using bash and/or > guile. Amazing work! I really appreciate that this initiative lowers the technical knowledge required for having a GuixSD system. > It uses guile-ncurses so that will have to be installed and be > in your load path. Would it make sense to add a check for it at configure time and conditionally compile and install the modules only if 'guile-ncurses' is found, like what is done for 'guile-json'? -- Mathieu Lirzin
Re: Unable to configure a system with 'cuirass-service'
ng0 writes: > Mathieu Lirzin writes: > >> Hi, >> >> Mathieu Lirzin writes: >> >>> Carlo Zancanaro writes: >>> >>>> On Thu, Dec 01 2016, ng0 wrote >>>>> I tried that before (though I did just think it was wrong) and now I >>>>> get the same message as yesterday: >>>>> >>>>> ... >>>>> >>>>> In gnu/services/cuirass.scm: 81: 1 [cuirass-shepherd-service #] In >>>>> unknown file:?: 0 [string=? "" ((# # # # ...))] >>>>> >>>>> ERROR: In procedure string=?: ERROR: In procedure string=: Wrong >>>>> type argument in position 2 (expecting string): (((#:name . "guix") >>>>> (#:url . "git://git.savannah.gnu.org/guix.git") (#:load-path . ".") >>>>> (#:file . "/.../cuirass/tests/gnu-system.scm") (#:proc . hydra-jobs) >>>>> (#:arguments (subset . "hello")) (#:branch . "master"))) >>>> >>>> It looks like cuirass is expecting the specifications to be a string, >>>> not a list. I don't know anything about cuirass, so I can't help you >>>> to configure the cuirass-service. >>>> >>>> Looking at the source, specifications has a comment ";string >>>> (file-name)". It looks like the "specifications" field of the >>>> configuration is just equivalent to the --specifications argument to the >>>> cuirass command, if that helps at all. >>> >>> Indeed, this is a mistake on my side. Here are 2 patches that should >>> fix this issue. >> >> I went ahead and pushed them in commits: >> >> - 44ccd9622eb4a0083d4f833a61172973390ca62b >> - 57aa94bd7e7d530e52356723c8f1dbf727144b25 >> >> Thanks, >> >> -- >> Mathieu Lirzin >> > > Thanks, I wasn't able to test them before and provide you with > feedback, I was just busy and the CI is kind of low priority for > gnunet. Sure no problem. -- Mathieu Lirzin
Re: Unable to configure a system with 'cuirass-service'
Hi, Mathieu Lirzin writes: > Carlo Zancanaro writes: > >> On Thu, Dec 01 2016, ng0 wrote >>> I tried that before (though I did just think it was wrong) and now I >>> get the same message as yesterday: >>> >>> ... >>> >>> In gnu/services/cuirass.scm: 81: 1 [cuirass-shepherd-service #] In >>> unknown file:?: 0 [string=? "" ((# # # # ...))] >>> >>> ERROR: In procedure string=?: ERROR: In procedure string=: Wrong >>> type argument in position 2 (expecting string): (((#:name . "guix") >>> (#:url . "git://git.savannah.gnu.org/guix.git") (#:load-path . ".") >>> (#:file . "/.../cuirass/tests/gnu-system.scm") (#:proc . hydra-jobs) >>> (#:arguments (subset . "hello")) (#:branch . "master"))) >> >> It looks like cuirass is expecting the specifications to be a string, >> not a list. I don't know anything about cuirass, so I can't help you >> to configure the cuirass-service. >> >> Looking at the source, specifications has a comment ";string >> (file-name)". It looks like the "specifications" field of the >> configuration is just equivalent to the --specifications argument to the >> cuirass command, if that helps at all. > > Indeed, this is a mistake on my side. Here are 2 patches that should > fix this issue. I went ahead and pushed them in commits: - 44ccd9622eb4a0083d4f833a61172973390ca62b - 57aa94bd7e7d530e52356723c8f1dbf727144b25 Thanks, -- Mathieu Lirzin
Re: Unable to configure a system with 'cuirass-service'
Hi, Carlo Zancanaro writes: > On Thu, Dec 01 2016, ng0 wrote >> I tried that before (though I did just think it was wrong) and now I >> get the same message as yesterday: >> >> ... >> >> In gnu/services/cuirass.scm: 81: 1 [cuirass-shepherd-service #] In >> unknown file:?: 0 [string=? "" ((# # # # ...))] >> >> ERROR: In procedure string=?: ERROR: In procedure string=: Wrong >> type argument in position 2 (expecting string): (((#:name . "guix") >> (#:url . "git://git.savannah.gnu.org/guix.git") (#:load-path . ".") >> (#:file . "/.../cuirass/tests/gnu-system.scm") (#:proc . hydra-jobs) >> (#:arguments (subset . "hello")) (#:branch . "master"))) > > It looks like cuirass is expecting the specifications to be a string, > not a list. I don't know anything about cuirass, so I can't help you > to configure the cuirass-service. > > Looking at the source, specifications has a comment ";string > (file-name)". It looks like the "specifications" field of the > configuration is just equivalent to the --specifications argument to the > cuirass command, if that helps at all. Indeed, this is a mistake on my side. Here are 2 patches that should fix this issue. >From 707d6f7255eeab39b6694bc81537966cbca0e61d Mon Sep 17 00:00:00 2001 From: Mathieu Lirzin Date: Thu, 1 Dec 2016 21:10:18 +0100 Subject: [PATCH 1/2] gnu: cuirass: Update to revision 2. * gnu/packages/ci.scm (cuirass): Update to revision 2. --- gnu/packages/ci.scm | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gnu/packages/ci.scm b/gnu/packages/ci.scm index f07e75a..d88ee6d 100644 --- a/gnu/packages/ci.scm +++ b/gnu/packages/ci.scm @@ -185,8 +185,8 @@ their dependencies.") (license l:gpl3+ (define-public cuirass - (let ((commit "7248c0038f3d0bfcf6c469d534efb4a13952c112") -(revision "1")) + (let ((commit "05eba838eab4ca928d8df926d70677821714e962") +(revision "2")) (package (name "cuirass") (version (string-append "0.0.1-" revision "." (string-take commit 7))) @@ -198,7 +198,7 @@ their dependencies.") (file-name (string-append name "-" version)) (sha256 (base32 - "0hkwh2pcz3wzg1n533ch2w7vwr97yr369q4ki0yqk99wfipjrydw" + "17bchil0dxflf74fncpr6drbpvc43a0hnvp22gp9w58kwpskwvri" (build-system gnu-build-system) (arguments '(#:phases -- 2.10.2 >From ab369ae1b894bcbb4045aa70b30399543eb4b050 Mon Sep 17 00:00:00 2001 From: Mathieu Lirzin Date: Thu, 1 Dec 2016 20:41:08 +0100 Subject: [PATCH 2/2] services: cuirass: Put specifications in the store. * gnu/services/cuirass.scm (): Change type of 'specifications' field to an alist to match the documentation example. (cuirass-shepherd-service): Store the provided specifications in a file. Use that file as the "--specification" argument. --- gnu/services/cuirass.scm | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/gnu/services/cuirass.scm b/gnu/services/cuirass.scm index d843c07..4975a7e 100644 --- a/gnu/services/cuirass.scm +++ b/gnu/services/cuirass.scm @@ -52,8 +52,8 @@ (default 60)) (database cuirass-configuration-database ;string (file-name) (default "/var/run/cuirass/cuirass.db")) - (specifications cuirass-configuration-specifications ;string (file-name) -(default "")) + (specifications cuirass-configuration-specifications ;specification-alist +(default '())) (use-substitutes? cuirass-configuration-use-substitutes? ;boolean (default #f)) (one-shot?cuirass-configuration-one-shot? ;boolean @@ -66,7 +66,7 @@ (let ((cache-directory (cuirass-configuration-cache-directory config)) (interval (cuirass-configuration-interval config)) (database (cuirass-configuration-database config)) - (specifications (cuirass-configuration-specifications config)) + (specs(cuirass-configuration-specifications config)) (use-substitutes? (cuirass-configuration-use-substitutes? config)) (one-shot?(cuirass-configuration-one-shot? config))) (list (shepherd-service @@ -78,9 +78,11 @@ #$@(if (string=? "" cache-directory) '() (list "--cache-directory" cache-directory)) -#$@(if (string=? "" specifications) +
Re: [PATCH 1/2] gnu: Add Cuirass.
David Craven writes: > LGTM! Pushed in commit 365de1e7a5b37f9fd88cd964cc7d47f6f729d053, with an updated Cuirass commit. Thanks. -- Mathieu Lirzin
Re: [PATCH 2/2] services: Add 'cuirass-service'.
Pushed in commit a7cf4eb6d99838606d8ecfa776f7e4920dfbb7f5 with bug fixed and requested changes. Thanks. -- Mathieu Lirzin
Re: [PATCH] doc: Suggest installing gvfs.
Hi, Ricardo Wurmus writes: > * gnu/system/examples/desktop.tmpl: Add gvfs to the system-wide list of > packages. > --- > gnu/system/examples/desktop.tmpl | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/gnu/system/examples/desktop.tmpl > b/gnu/system/examples/desktop.tmpl > index 82687e7..21b4563 100644 > --- a/gnu/system/examples/desktop.tmpl > +++ b/gnu/system/examples/desktop.tmpl > @@ -4,7 +4,7 @@ > > (use-modules (gnu) (gnu system nss)) > (use-service-modules desktop) > -(use-package-modules certs) > +(use-package-modules certs gnome) > > (operating-system >(host-name "antelope") > @@ -42,6 +42,7 @@ > >;; This is where we specify system-wide packages. >(packages (cons* nss-certs ;for HTTPS access > + gvfs ;for user mounts > %base-packages)) > >;; Add GNOME and/or Xfce---we can choose at the log-in IMO 'gvfs' is a reasonable default for a desktop configuration. So I think this patch is a good idea. Thanks. -- Mathieu Lirzin
Re: [PATCH] gnu: services: Add git-service.
Mathieu Lirzin writes: > 宋文武 writes: > >> From: ng0 >> >> * gnu/services/version-control.scm: New file. >> * gnu/local.mk (GNU_SYSTEM_MODULES): Add it. >> * doc/guix.texi (Misellaneous Services)(Version Control): New section. > > but I find this notation confusing, since "Version Control" belongs to ^^^ Please ignore this "but" that shouldn't be here. -- Mathieu Lirzin
Re: [PATCH] gnu: services: Add git-service.
Hello, 宋文武 writes: > From: ng0 > > * gnu/services/version-control.scm: New file. > * gnu/local.mk (GNU_SYSTEM_MODULES): Add it. > * doc/guix.texi (Misellaneous Services)(Version Control): New section. but I find this notation confusing, since "Version Control" belongs to "Miscellaneous Services". @node identifiers are unique, so it is reasonable to refers to them with '()', and use '<>' for their parts as suggested by GCS: https://www.gnu.org/prep/standards/html_node/Indicating-the-Part-Changed.html#Indicating-the-Part-Changed Thanks. -- Mathieu Lirzin
Re: [PATCH 1/1] gnu: gnupg: Update to 2.1.16.
Hi, Leo Famulari writes: > On Sun, Nov 20, 2016 at 12:41:31AM +0200, Efraim Flashner wrote: >> Looks like they forgot to bootstrap it then. > > Because I altered two Makefile.am files in the 'patch-paths' phase, I > had to re-do the bootstrap in order for the Makefiles to be regenerated. > > I'm not an expert on Autotools. Does anyone know if there is a better > way? I have not tried but unless some weird issue, I think you can safely replace "/bin/pwd" directly in the generated Makefile(s) instead of the Makefile.am sources. This should fix the Autotools dependency and the warning. -- Mathieu Lirzin
Re: Web site now uses Haunt
l...@gnu.org (Ludovic Courtès) writes: > I moved the web site to Haunt like I did earlier with that of Guix: > > https://lists.gnu.org/archive/html/guix-devel/2016-10/msg01307.html > > So now the news page is more pleasant to the eye: > > https://www.gnu.org/software/guile/news/ > > I figured probably nobody would dislike the change. :-) > > Anyway, please report any issues! > > I’ll email to update the feed URL in planet.gnu.org and > scheme.dk/planet. > > Thanks again to Assaf Gordon who provided me with a raw dump of the news > entries from Savannah! Nice! -- Mathieu Lirzin
Re: [Patch 1/10] Add pjproject.
Hi, Ricardo Wurmus writes: > PS: for future reference, this > > (lambda (file) > (if (or (string=? file ".") > (string=? file "..")) > #f > #t)) > > could more concisely be written as > > (cute (not (or (string=? <> ".") >(string=? <> ".." I think you mean something like this instead: (lambda (file) (not (or (string=? file ".") (string=? file ".." Did I miss something? -- Mathieu Lirzin
Re: [PATCH 2/2] services: Add 'cuirass-service'.
Hello David, David Craven writes: > Do we need to export all of these? > > +cuirass-configuration-cache-directory > +cuirass-configuration-group > +cuirass-configuration-interval > +cuirass-configuration-database > +cuirass-configuration-specifications > +cuirass-configuration-use-substitutes? > +cuirass-configuration-one-shot? > +%default-cuirass-configuration Since the data type is documented in the manual, the idea was to export the procedures that allow manipulating this type in a REPL. However since it appears that other services are not doing that, I think it is better to remove them. > Is %default-cuirass-configuration needed? The benefit is a slightly more meaningful default value for #:CONFIG in the 'cuirass-service' procedure documentation. However I am not sure if that helps much. WDYT? Thanks for the review. -- Mathieu Lirzin
[PATCH 0/2] Cuirass package + service.
Hello, Here is a package definition and service for Cuirass. As documented both in the second patch, the service is not really useful as it is. TL;DR Cuirass needs to be launched the first time with the "--specifications" option and then without it, because it has a side effect on the database. As a consequence the same specifications will be re-added each time the service is restarted. I think we want to allow users to add additional specifications at runtime without having to reconfigure the system or even restart Cuirass, I think it would make sense for cuirass to use a Client+Server architecture communicating over Socket. If nobody has a better idea, I will start working on that (taking inspiration from the Shepherd). Thanks, Mathieu Lirzin (2): gnu: Add Cuirass. services: Add 'cuirass-service'. doc/guix.texi| 86 +++ gnu/local.mk | 1 + gnu/packages/ci.scm | 51 +++ gnu/services/cuirass.scm | 128 +++ 4 files changed, 266 insertions(+) create mode 100644 gnu/services/cuirass.scm -- 2.9.3
[PATCH 1/2] gnu: Add Cuirass.
* gnu/packages/ci.scm (cuirass): New variable.
Co-authored-by: Jan Nieuwenhuizen
---
gnu/packages/ci.scm | 51 +++
1 file changed, 51 insertions(+)
diff --git a/gnu/packages/ci.scm b/gnu/packages/ci.scm
index 3f54ff1..3cacc23 100644
--- a/gnu/packages/ci.scm
+++ b/gnu/packages/ci.scm
@@ -1,5 +1,7 @@
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2015 Eric Bavier
+;;; Copyright © 2016 Jan Nieuwenhuizen
+;;; Copyright © 2016 Mathieu Lirzin
;;;
;;; This file is part of GNU Guix.
;;;
@@ -181,3 +183,52 @@
release that uses a purely functional language to describe build jobs and
their dependencies.")
(license l:gpl3+
+
+(define-public cuirass
+ (let ((commit "24d45055077911fb92aaa67762d442af44d20403")
+(revision "1"))
+(package
+ (name "cuirass")
+ (version (string-append "0.0.1-" revision "." (string-take commit 7)))
+ (source (origin
+(method git-fetch)
+(uri (git-reference
+ (url "https://notabug.org/mthl/cuirass";)
+ (commit commit)))
+(file-name (string-append name "-" version))
+(sha256
+ (base32
+ "0r7jnrnkxgwj9iplp9l129xwi2w6zg0ndavm0sxz7ni49qsrx89y"
+ (build-system gnu-build-system)
+ (arguments
+ '(#:phases
+ (modify-phases %standard-phases
+ (add-after 'unpack 'bootstrap
+ (lambda _ (zero? (system* "sh" "bootstrap"
+ (add-after 'install 'wrap-program
+ (lambda* (#:key inputs outputs #:allow-other-keys)
+ ;; Wrap the 'cuirass' command to refer to the right modules.
+ (let* ((out(assoc-ref outputs "out"))
+ (sqlite (assoc-ref inputs "guile-sqlite3"))
+ (guix (assoc-ref inputs "guix"))
+ (mods (string-append out "/share/guile/site/2.0:"
+ sqlite "/share/guile/site/2.0:"
+ guix "/share/guile/site/2.0")))
+ (wrap-program (string-append out "/bin/cuirass")
+ `("GUILE_LOAD_PATH" ":" prefix (,mods))
+ `("GUILE_LOAD_COMPILED_PATH" ":" prefix (,mods)
+ (inputs
+ `(("guile" ,guile-2.0)
+ ("guile-json" ,guile-json)
+ ("guile-sqlite3" ,guile-sqlite3)
+ ("guix" ,guix)))
+ (native-inputs
+ `(("autoconf" ,autoconf)
+ ("automake" ,automake)
+ ("pkg-config" ,pkg-config)))
+ (synopsis "Continuous integration system")
+ (description
+ "Cuirass is a continuous integration system which uses GNU Guix. It is
+intended as replacement for Hydra.")
+ (home-page "https://notabug.org/mthl/cuirass";)
+ (license l:gpl3+
[PATCH 2/2] services: Add 'cuirass-service'.
* gnu/services/cuirass.scm: New file.
* gnu/local.mk (GNU_SYSTEM_MODULES): Add it.
* doc/guix.texi (Continuous integration): New node.
---
doc/guix.texi| 86 +++
gnu/local.mk | 1 +
gnu/services/cuirass.scm | 128 +++
3 files changed, 215 insertions(+)
create mode 100644 gnu/services/cuirass.scm
diff --git a/doc/guix.texi b/doc/guix.texi
index 86b82c8..f9cb9e4 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -7687,6 +7687,7 @@ declaration.
* Mail Services:: IMAP, POP3, SMTP, and all that.
* Web Services::Web servers.
* Network File System:: NFS related services.
+* Continuous integration:: The cuirass service.
* Miscellaneous Services:: Other services.
@end menu
@@ -10524,6 +10525,91 @@ If it is @code{#f} then the daemon will use the host's fully qualified domain na
@end table
@end deftp
+@node Continuous integration
+@subsubsection Continuous integration
+
+@cindex continuous integration
+@uref{https://notabug.org/mthl/cuirass, Cuirass} is a continuous
+integration tool for Guix. It can be used both for development and
+for providing substitutes to others (@pxref{Substitutes}).
+
+The @code{(gnu services cuirass)} module provides the following service.
+
+@deffn {Scheme Procedure} cuirass-service @
+ [#:config @code{%default-cuirass-configuration}]
+Return a service that runs @command{cuirass}.
+
+The @var{#:config} keyword argument specifies the configuration for
+@command{cuirass}, which must be a @code{}
+object, by default it doesn't provide any build job. If you want to
+provide your own configuration you will most likely use the
+@code{cuirass-configuration} special form which returns such objects.
+@end deffn
+
+In order to add build jobs you will have to set the
+@code{specifications} field. Due to current limitations of Cuirass, the
+specifications are re-added each time the associated Shepherd service is
+restarted. This is indeed a bug. Here is an example of a cuirass
+service defining a build job based on a specification that can be found
+in Cuirass source tree.
+
+@example
+(let ((spec `((#:name . "guix")
+ (#:url . "git://git.savannah.gnu.org/guix.git")
+ (#:load-path . ".")
+ ;; Adapt to a valid absolute file name.
+ (#:file . "/.../cuirass/tests/gnu-system.scm")
+ (#:proc . hydra-jobs)
+ (#:arguments (subset . "hello"))
+ (#:branch . "master"
+ (cuirass-service #:config (cuirass-configuration
+ (specifications (list spec)
+@end example
+
+While information related to build jobs are located directly in the
+specifications, global parameters for the @command{cuirass} process are
+accessible in other @code{cuirass-configuration} fields.
+
+@deftp {Data Type} cuirass-configuration
+Data type representing the configuration of Cuirass.
+
+@table @asis
+@item @code{cache-directory} (default: "")
+Location of the repository cache.
+
+@item @code{user} (default: "cuirass")
+Owner of the @code{cuirass} process.
+
+@item @code{group} (default: "cuirass")
+Owner's group of the @code{cuirass} process.
+
+@item @code{interval} (default: 60)
+Number of seconds between the poll of the repositories followed by the
+Cuirass jobs.
+
+@item @code{database} (default: "/var/run/cuirass/cuirass.db")
+Location of sqlite database which contains the build results and previously
+added specifications.
+
+@item @code{specifications} (default: @code{'()})
+A list of specifications, where a specification is an association list
+(@pxref{Associations Lists,,, guile, GNU Guile Reference Manual}) whose
+keys are keywords (@code{#:keyword-example}) as shown in the example
+above.
+
+@item @code{use-substitutes?} (default: @code{#f})
+This allows using substitutes to avoid building every dependencies of a job
+from source.
+
+@item @code{one-shot?} (default: @code{#f})
+Only evaluate specifications and build derivations once.
+@end table
+@end deftp
+
+@defvar %default-cuirass-configuration
+This global variable contains a @code{cuirass-configuration} where all
+the fields contain their default value.
+@end defvar
@node Miscellaneous Services
@subsubsection Miscellaneous Services
diff --git a/gnu/local.mk b/gnu/local.mk
index c6cd586..e0ec339 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -392,6 +392,7 @@ GNU_SYSTEM_MODULES =\
%D%/services/admin.scm \
%D%/services/avahi.scm \
%D%/services/base.scm\
+ %D%/services/cuirass.scm \
%D%/services/databases.scm \
%D%/services/dbus.scm\
%D%/services/desktop.scm \
diff --git a/gnu/services/cuirass.scm b/gnu/services/cuirass.scm
new file mode 100644
index 000..93e2805
--- /dev/null
+++ b/gnu/services/cuirass.scm
@@ -0,0
Re: using Cuirass to track a guix packages' git
Jan Nieuwenhuizen writes: > Mathieu Lirzin writes: > >> David Craven writes: >> >>> I think the web interface and the json API are two different >>> "projects". >> >> Agreed. > > Oh! Then why choose json (poor-man's-sexps?) over sexps? I'm mostly > just using sexps with read and write, and pipe through json translators > when crossing the border to the javascript realm. AIUI JSON usage is not limited to JavaScript since almost every programming language has a parser for it. IMO, this is its main advantage which overcomes its technical limitations. However if using both S-EXP and JSON is possible without adding complexity we could provide them both throught HTTP. -- Mathieu Lirzin
Re: using Cuirass to track a guix packages' git
David Craven writes: > I think the web interface and the json API are two different > "projects". Agreed. >> just a matter of knowing how to do the javascript stuff. :) > > Many people think that JS is a toy language, JS the good parts is a > weekend read (like 100p or something) that might change your > perspective and covers everything, you already know functional > programming. > https://drive.google.com/open?id=0B-QBlsZR8DS4ZUJLcnkzdkxZVkU Sounds interesting. I will try to find some time to read this book. Thanks, -- Mathieu Lirzin
Re: using Cuirass to track a guix packages' git
Jan Nieuwenhuizen writes: > Mathieu Lirzin writes: > >>> Yes, I think I found this, I can see json in my browser window...but >>> that's not really a web view yet (no criticism, I'm just wondering...) >> >> Sorry I misread what you meant by web view. I don't have much >> experience in Web programming, I guess an "easy" way (for a Scheme >> programmer at least) to achieve something quickly would be to generate >> static HTML from SXML and procedures that convert Cuirass data structures >> to SXML. > > Hmm...interesting. The json thing made me think we'd be interfacing > with some javascript stuff, to produce pages like > > http://hydra.gnu.org/queue > http://hydra.gnu.org/status > http://hydra.gnu.org/jobset/gnu/master#tabs-jobs > > i.e., browsable status reports for `normal people'. That could be done this way which would certainly be more useful. It is just a matter of knowing how to do the javascript stuff. :) -- Mathieu Lirzin
Re: using Cuirass to track a guix packages' git
Jan Nieuwenhuizen writes: > Mathieu Lirzin writes: > >>> Thanks! I'd really love to get a working Guix-based ci system and >>> Cuirass is already very close to the minimal set that I need. I have >>> a working patch to add building of VMs (a la hydra/guix-system.scm) but >>> it needs a bit of cleanup work. >> >> Nice! > > I figure we experiment and maintain this in Cuirass and move into Guix > again later. This is a good strategy I think. >> There is a basic Guile Web server which is runnable via >> 'run-cuirass-server' procedure. There is only one JSON ressource which >> is accessible from "/specifications" and "/jobsets" routes. To use the >> server you have to parameterize the '%package-database' parameter to >> point to an SQLite file with specifications in it. > > Yes, I think I found this, I can see json in my browser window...but > that's not really a web view yet (no criticism, I'm just wondering...) Sorry I misread what you meant by web view. I don't have much experience in Web programming, I guess an "easy" way (for a Scheme programmer at least) to achieve something quickly would be to generate static HTML from SXML and procedures that convert Cuirass data structures to SXML. >> WHAT NEEDS TO be done is to provide more JSON ressources (inspired by >> Hydra API) by translating request to SQL queries. A command line >> interface would be a nice addition too. > > If this is inspired by Hydra does it mean you plan to somehow use (parts > of?) the Hydra web engine to present views using this json? The idea is to reuse Emacs Hydra interface in Guix if possible. :) -- Mathieu Lirzin
Re: using Cuirass to track a guix packages' git
Jan Nieuwenhuizen writes: > Mathieu Lirzin writes: > > Hi Mathieu! > >>> I had some trouble with the #:no-compile? option, it's currently >>> specified twice. On the Cuirass side I think it should be a property >>> of the spec, but it seems it gets only passed as part of the >>> arguments. Ideas? >> >> OK, I think I got it. With the idea to move to a client/server >> architecture in the future, Cuirass uses the database to keep track of >> the specifications (in a weird way). When new specifications are added >> with --specifications, they are first put in the database before being >> fetched back with the previously added ones. As a consequence if a key >> in the specification is not handle when adding the spec to the database >> in 'db-add-specification' procedure, then it will be ignored. >> >> Does it make sense? > > That makes sense; thanks, I understand. > >> If yes, then I guess that patch 2 and 3 can easily be adapted to use >> only '#:no-compile?' as a property. > > Yes, that works. I was wondering if using #:compile? would be better, > but I kind of like the sqlite default of `0' being translated to #f and > I did not want to change the default setting. WDYT? Intuitively I would prefer "#:compile?" but both are OK, so we can stick with "#:no-compile?" if that's more convenient. >>> Subject: [PATCH 3/4] tests: track cuirass' git. >>> +(define-public cuirass-git >>> + (package >>> +(name "cuirass-git") >> >> Since this is a package definition of Cuirass, would it make sense to >> rename it to "guix.scm" recommended in Guix manual? > > Sure, done. > >> Is the (ci) module definition required? > > Not in guix.scm per se, so I have removed it there. > > However, in tracking of a packages' git it is necessary for the package > description being available to guix build, which AIUI means that its > package definition must be available in a module in the > GUIX_PACKAGE_PATH. > > I am using this Guix package definition of Cuirass in the > tests/hello-git.scm test, tracking Cuirass's git. So, therefore we need > something like the (ci) module in guix/. This now works by pre-inst-env > adding the guix/ sub-directory to the GUIX_PACKAGE_PATH. OK. >> Can you send the updated patches? > > Sure, find attached. Pushed with minor cosmetic changes. :) > I have refrained from describing this Git-tracking > feature in README because it would need a version of these patches to go > in first. When it works with your notabug git source url, we can add a > description. to help people going. Given the current state of Cuirass, I think it is OK to not provide documentation while experimenting. >> I think you have done an amazing job. Thank you! > > Thanks! I'd really love to get a working Guix-based ci system and > Cuirass is already very close to the minimal set that I need. I have > a working patch to add building of VMs (a la hydra/guix-system.scm) but > it needs a bit of cleanup work. Nice! > I'm wondering about the status of the http integration. I have played a > bit with what there is now but do not understand how to use it or what > steps would be needed, what direction to go, to help getting a minimal > web view up. There is a basic Guile Web server which is runnable via 'run-cuirass-server' procedure. There is only one JSON ressource which is accessible from "/specifications" and "/jobsets" routes. To use the server you have to parameterize the '%package-database' parameter to point to an SQLite file with specifications in it. What needs to be done is to provide more JSON ressources (inspired by Hydra API) by translating request to SQL queries. A command line interface would be a nice addition too. Thanks. -- Mathieu Lirzin
Re: using Cuirass to track a guix packages' git
"
> export PATH
>
> +GUIX_PACKAGE_PATH="guix${GUIX_PACKAGE_PATH:+:}$GUIX_PACKAGE_PATH"
> +export GUIX_PACKAGE_PATH
> +
> exec "$@"
> diff --git a/guix/ci.scm b/guix/ci.scm
> new file mode 100644
> index 000..0eb886a
> --- /dev/null
> +++ b/guix/ci.scm
> @@ -0,0 +1,65 @@
> +;;; GNU Guix --- Functional package management for GNU
> +;;; Copyright © 2016 Jan Nieuwenhuizen
> +;;;
> +;;; This file is part of GNU Guix.
> +;;;
> +;;; GNU Guix is free software; you can redistribute it and/or modify it
> +;;; under the terms of the GNU General Public License as published by
> +;;; the Free Software Foundation; either version 3 of the License, or (at
> +;;; your option) any later version.
> +;;;
> +;;; GNU Guix is distributed in the hope that it will be useful, but
> +;;; WITHOUT ANY WARRANTY; without even the implied warranty of
> +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +;;; GNU General Public License for more details.
> +;;;
> +;;; You should have received a copy of the GNU General Public License
> +;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
> +
> +(define-module (ci)
> + #:use-module ((guix licenses) #:prefix l:)
> + #:use-module (gnu packages)
> + #:use-module (guix packages)
> + #:use-module (guix git-download)
> + #:use-module (gnu packages autotools)
> + #:use-module (gnu packages base)
> + #:use-module (gnu packages databases)
> + #:use-module (gnu packages guile)
> + #:use-module (gnu packages package-management)
> + #:use-module (gnu packages pkg-config)
> + #:use-module (guix build-system gnu))
> +
> +(define-public cuirass-git
> + (package
> +(name "cuirass-git")
> +(version "0.0")
> +(source (origin
> + (method git-fetch)
> + (uri (git-reference
> +(url "https://notabug.org/mthl/cuirass";)
> +(commit "master")))
> + (sha256
> + (base32
> +"1jw3smw6axqr58ahkyjncygv0nk3hdrqkv0hm4awwj0hg5nl3d2p"
> +(build-system gnu-build-system)
> +(arguments
> + `(#:phases
> +(modify-phases %standard-phases
> + (add-after 'unpack 'bootstrap
> +(lambda _ (zero? (system* "sh" "bootstrap")))
> +(native-inputs
> + `(("autoconf" ,autoconf)
> + ("automake" ,automake)
> + ("guile" ,guile-2.0)
> + ("guile-json" ,guile-json)
> + ("guile-sqlite3" ,guile-sqlite3)
> + ("guix" ,guix)
> + ("pkg-config" ,pkg-config)
> + ("sqlite" ,sqlite)))
> +(synopsis "Continuous integration system")
> +(description
> + "Cuirass is a continuous integration system which uses GNU Guix. It is
> +intended as replacement for Hydra.")
> +(home-page "https://notabug.org/mthl/cuirass";)
> +(license l:gpl3+)))
> +
Since this is a package definition of Cuirass, would it make sense to
rename it to "guix.scm" recommended in Guix manual? Is the (ci) module
definition required?
> diff --git a/tests/guix-track-git.scm b/tests/guix-track-git.scm
> new file mode 100644
> index 000..15fd575
> --- /dev/null
> +++ b/tests/guix-track-git.scm
> @@ -0,0 +1,225 @@
> +;;; guix-track-git.scm -- job specification tracking a guix packages's git
> +;;; Copyright © 2012, 2013, 2014, 2015, 2016 Ludovic Courtès
> +;;; Copyright © 2016 Mathieu Lirzin
> +;;; Copyright © 2016 Jan Nieuwenhuizen
> +;;;
> +;;; This file is part of Cuirass.
> +;;;
> +;;; GNU Guix is free software; you can redistribute it and/or modify it
> +;;; under the terms of the GNU General Public License as published by
> +;;; the Free Software Foundation; either version 3 of the License, or (at
> +;;; your option) any later version.
> +;;;
> +;;; GNU Guix is distributed in the hope that it will be useful, but
> +;;; WITHOUT ANY WARRANTY; without even the implied warranty of
> +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +;;; GNU General Public License for more details.
> +;;;
> +;;; You should have received a copy of the GNU General Public License
> +;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
> +
> +;;;
> +;;; This file defines build jobs for the Hydra continuation integration
> +;;; tool.
> +;;;
> +
> +(define local-guix (string-append (getenv "HOME") "/src/guix"))
> +(define local-cuirass (string-append (getenv "HOME") "/src/cuirass/
Re: using Cuirass to track a guix packages' git
Hello Jan, Jan Nieuwenhuizen writes: > I have been playing with Cuirass and I like it a lot! Cool. :) I want to let you know that I have just started looking at your patches. I have been quite busy lately. Sorry for the latency. Next time I will let you know sooner if you should expect a delay. > Next to replacing Hydra for GuixSD, there is another use case that I'd > like Cuirass to support: tracking an (any) upstream packages' git. This is highly desirable indeed. > When the target of your continuous integration is not Guix itself but > some specific package, you may well want to allow usage of substitutes > (patch 1). Agreed. > Assuming you have checked-out guix and cuirass in ~/src/guix and > ~/src/cuirass, doing > >./pre-inst-env cuirass --use-substitutes > --specifications=tests/hello-git.scm > > will monitor any changes to Cuirass' git repository and rebuild the > latest commit of the Cuirass package using Guix (patch 2 and 3). > > Of course, a build a failure should not crash cuirass and also be > noted/stamped, not repeated every heartbeat (patch 4). yes :) > I had some trouble with the #:no-compile? option, it's currently > specified twice. On the Cuirass side I think it should be a property > of the spec, but it seems it gets only passed as part of the > arguments. Ideas? No idea for now. I will comment/review your code in details in a following mail. I should be able to do that in the next 48H. Thank you for your patches, patience and courage! -- Mathieu Lirzin
Re: [PATCH] Clean all .go in clean-go
Hello, Eric Bavier writes: > From: Eric Bavier > > I encountered a runtime error recently while running `guix system > reconfigure`. Thinking this might be because of an ABI break I ran `make > clean-go && make` before trying again, with the same result. > > It turns out a module had been renamed, in this case fish.scm to shells.scm, > but I had overlooked this and failed to update the list of modules in my > config.scm's (use-package-modules ...) statement. However, I still had a > stale fish.go sitting in my build directory, which `make clean-go` had failed > to clean up, and guix happily loaded it. > > I believe the following patch is an appropriate way to avoid such errors in > the future. AIUI the main problem is that the API for defining "config.scm" is not stable because of the package modules renames. Since package names are more stable, I think that configuration files should import (gnu packages) and use 'specification->package' when possible to resolve packages, instead of relying on the module names. Maybe we should fix the "config.scm" documentation? In regards of the .go files remaining in the build directory, I agree that this is not good, however I don't think it is worth trying to fix this issue which equally applies to every file generated by Make. Using wildcards can be tempting in such cases but it can lead to accidental file deletions which is worse IMO. As a consequence I would prefer keeping the current 'clean-go' rule. -- Mathieu Lirzin
Re: [PATCH] Fix compiling on CentOS 7.
Roel Janssen writes: > Thanks. Mathieu, could you revert your patch, or do you want me to look > at it? Feel free to take care of it, unless someone strongly object this change in the following days. -- Mathieu Lirzin
Re: [PATCH] Fix compiling on CentOS 7.
Hi Roel Janssen writes: > Alex Kost writes: > >> Tomáš Čech (2016-08-27 09:57 +0300) wrote: >> >>> On Fri, Aug 26, 2016 at 09:48:36PM +0200, Roel Janssen wrote: >>>>Dear Guix, >>>> >>>>Due to an old Automake version (1.13), running the `./configure' phase on >>>>CentOS 7 fails with: >>>> >>>>> autoreconf: running: automake --add-missing --copy --force-missing >>>>> configure.ac:21: warning: The 'AM_PROG_MKDIR_P' macro is deprecated, and >>>>> its use is discouraged. >>>>> configure.ac:21: You should use the Autoconf-provided 'AC_PROG_MKDIR_P' >>>>> macro instead, >>>>> configure.ac:21: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your >>>>> Makefile.am files. >>>>> Makefile.am:422: warning: AM_GNU_GETTEXT used but 'po' not in SUBDIRS >>>>> automake: error: cannot open < ./%D%/guix.texi: No such file or directory >>>>> autoreconf: automake failed with exit status: 1 >>>> >>>>(It does not replace %D% with the appropriate directory..) >>>> >>>>The attached patch replaces each instance of %D%, which I believe stands >>>>for the current subdirectory from the project root, with the appropriate >>>>directory. With these changes, I've been able to compile GNU Guix on >>>>CentOS 7. >>>> >>>>I am not sure how this change impacts custom configure options, so I >>>>would like to ask someone with more Automake knowledge and experience to >>>>elaborate on the possible downsides of applying this patch. >>>> >>>>If this change is acceptable to the project, I will update the commit >>>>message to a more detailed and conforming message. Suggestions are >>>>welcome here though. >>>> >>>>What do you think about making Guix compilable on this "stable" >>>>distribution? :-) >>> >>> I'd prefer to keep this patch in CentOS (or similar distribution with >>> outdated software) as distro specific. I can assume that CentOS 8 >>> won't need it and you can just drop it for newer releases. >> >> I also think this patch should stay on the CentOS side. Roel, what you >> suggest is a revert of commit c0d2e7b: >> >> http://git.savannah.gnu.org/cgit/guix.git/commit/?id=c0d2e7b197a3c511eb1bf60b61ee6fdc673e36f4 > > Ha! I hadn't seen that commit. It is indeed a revert of this commit. > > Let me rephrase my thought: > I don't see any good reason to break compatibility with well established > distributions. And the commit message does not state why a macro is > better than spelling out the relative path. > > Because the above commit shows that we used to be able to compile GNU > Guix without the macro, I am more confident that it is > harmless. Possibly Mathieu can elaborate on the necessity of the > change. :) There is no necessity in that change, it was just introduced because the it can be confusing for some people that the Makefile fragment contains file names relative to the 'top_srcdir' not the actual fragment location. Moreover it has the slight benefit of potentially avoiding some manual modifications when moving files around. IMO supporting the Automake versions distributed in Debian Stable and The last RHEL/CentOS version is desirable and the above feature doesn't worth the breakage. So I am in favor of reverting my commit. I think it would make sense to explicitly state in the manual which version of Autoconf, Automake, etc we are supporting: https://www.gnu.org/software/guix/manual/guix.html#Building-from-Git -- Mathieu Lirzin
Re: [PATCH] ui: 'package->recutils' serializes the source field.
David Craven writes: >> unless you convince the Guix maintainers that my doubt are not legitimate > > I'm sorry but I haven't heard anyone except you express doubt. I made > several arguments to which you did not respond. Who else except you do > you think I have to convince? I have already express my point. Please address your arguments to not to me. > You made no effort on your part as I explained in the previous mail. I > don't know what exactly why you are against this change, but I'm > doubting that it has anything to do with FSDG compliance. This is your version of the story. I have tried to explain to you how the change you have proposed is likely to be related to the "guix build --source" FSDG issue. Claiming that I have not made any effort because you are not convinced is unfair. -- Mathieu Lirzin
Re: [PATCH] ui: 'package->recutils' serializes the source field.
David Craven writes: > Hi Mathieu, > >> No that's not a desired formatting, it should be space separated like >> the systems list IMO. > >> But I guess we aren't telling the full >> story and should tell the user that we made post download >> modifications to the tarball to comply with the free software >> distribution guidelines. > > Can we move forward on this then if we incorporate Alex's changes and > these suggestions? > > I'll provide a few pointers for a stronger argument for the next one > you have (if you don't mind) ;-) > > You made the statement that the FSDG wasn't clear enough on the > subject to make a decision and was open for interpretation. Then you > made use of "case law" referring to the guix package -S thread. > > You also made the statement: >> I am just claiming that the two things above are equivalent and that as >> a consequence we can't refuse one and accept the other. I am not >> discussing the "why", only applying logic. > > I would have expected you to provide a compelling argument for why > these things are equivalent, since it wasn't obvious to me. Making use > of case law is a valid argument, but you'd have to explain why and how > it applies to cast reasonable doubt that this is a FSDG issue. IMO you > did not do so sufficiently to merit escalating the discussion to a > different mailing list. When someone wants to introduce some change, it is up to him to convince others to accept this change, not the other way. This discussion is already escalating in a way where you are waisting your energy (and mine too), Guix-devel is not the relevant place for talking about FSDG compliance. I have already explain my reasons and I will not repeat myself. If you don't want to take the time to discuss this on the relevant mailing list, then nothing will move unless you convince the Guix maintainers that my doubt are not legitimate. -- Mathieu Lirzin
Re: [PATCH] ui: 'package->recutils' serializes the source field.
David Craven writes: > Sometimes it's hard to admit when you are wrong, but I think in > practice people barely take notice if you quickly admit you are > wrong and move on. If you drag it out, people are definitively > going to remember. > > Claiming that you applied logic to arrive at the conclusion that > > - Providing a user tool to fetch a tarball > - Displaying a direct link to a tarball in our UI > > are the same thing is nonsense. If I disagree with you doesn't mean I am wrong. Please don't act as if you were in a position to decide who is wrong. Trying to persuade me that it would be better for my reputation to agree with you won't work. > Asking me to start a discussion on the linux-libre mailing list over > this is an unreasonable request. Being careful about FSDG compliance is not unreasonable. > The only way I can see these two things being equal is if you > say: > > class Thing > class UserTool extends Thing > class DirectLink extends Thing > > typeof UserTool == typeof DirectLink ;-) > > I had a class on java - which I didn't attend - and passed > an exam - but I never wrote a single line of java. Pretty > interesting what will pass as a java programmer don't you > think? =P Sorry, but I don't understand what you are trying to say. -- Mathieu Lirzin
Re: [PATCH] gnu: st: Mov to terminals.scm.
iyzs...@member.fsf.org (宋文武) writes: > ng0 writes: > >> Hi, >> >> I think it's pointless to have a suckless.scm which bundles all software >> which just happens to follow suckless ideology/goals or be hosted >> there. >> That's why I did not commit ii to suckless but to irc.scm, no one will >> look into suckless.scm when what they really are looking for is not >> $suckless but application xy. >> I try to unbundle and remove suckless.scm with the next patches. > > Well, it's difficult to choose the "right" category for packages. > For example, 'dmenu' shouldn't go to 'wm.scm', it has nothing to > do with window managers. > > When a project makes multiple softwares, I think it's easier to > put all of them in one project file, eg: gnome and freedesktop. So you are in favour of keeping (gnu packages suckless)? -- Mathieu Lirzin
Re: [PATCH] ui: 'package->recutils' serializes the source field.
Alex Kost writes: > Mathieu Lirzin (2016-08-08 20:53 +0300) wrote: > >> David Craven writes: >> >>> Quoting Ludo from the thread you mentioned: >>> >>>> (Besides, our package meta-data would probably still refer to the “real” >>>> home page of the package, from which it’s trivial to get the unmodified >>>> tarball.) >>> >>> The discussion only applies to 'guix build --source' and I can't see any >>> indication from reading the thread that displaying the original source url >>> would be in any way problematic. Can you quote something from that >>> thread that would indicate otherwise? >> >> I don't need to quote anything to think that: >> >> - Providing a user tool to fetch a tarball >> - Displaying a direct link to a tarball in our UI > > But a user already can look at any package info (including the source > URL) using "guix edit" command, so I don't see a reason why "guix > package --show" can't display the same info. I am just claiming that the two things above are equivalent and that as a consequence we can't refuse one and accept the other. I am not discussing the "why", only applying logic. -- Mathieu Lirzin
Re: [PATCH] gnu: Add tint2.
l...@gnu.org (Ludovic Courtès) writes: > Mathieu Lirzin skribis: > >> +(synopsis "Lightweight taskbar") > > Nitpick: I’d write “task bar” as two words, but I’m conservative. > > Ludo’. Pushed in commit 751f68717538ae0d145d348fca04aebc713740ac. -- Mathieu Lirzin
Re: [PATCH] ui: 'package->recutils' serializes the source field.
David Craven writes: > Quoting Ludo from the thread you mentioned: > >> (Besides, our package meta-data would probably still refer to the “real” >> home page of the package, from which it’s trivial to get the unmodified >> tarball.) > > The discussion only applies to 'guix build --source' and I can't see any > indication from reading the thread that displaying the original source url > would be in any way problematic. Can you quote something from that > thread that would indicate otherwise? I don't need to quote anything to think that: - Providing a user tool to fetch a tarball - Displaying a direct link to a tarball in our UI ... have the same "steer users" effect. Feel free to disagree, however when doubt emerges about FSDG compliance, a consensus needs to be reached on . If you want your change to be included in Guix, please start a discussion on that mailing list explaining what you are proposing and ask if other people thinks this is OK in regards of the FSDG. -- Mathieu Lirzin
Re: [PATCH] ui: 'package->recutils' serializes the source field.
David Craven writes: > Quoting FSDG: > A free system distribution must not steer users towards obtaining any > nonfree information for practical use, or encourage them to do so. > > We are not steering or encouraging users to do any thing by displaying > the source url of the tarball, That's an interpretation of it. I think that point deserves a discussion on mailing list, before including such change in Guix UI. For some background on the 'guix build --source' issue, Please read the full thread on https://lists.nongnu.org/archive/html/gnu-linux-libre/2013-09/msg1.html. >we are merely providing factual non-opinionated information. IMO, Distributing software is always opinionated. :) -- Mathieu Lirzin
Re: [PATCH] gnu: st: Mov to terminals.scm.
ng0 writes: > Mathieu Lirzin writes: > >> I don't have an opinion on the move, however when moving packages across >> modules your have to keep track of the copyrights. > > Oh... Okay, I forgot about that, I never moved packages. Thanks for > pointing it out to me. > I know that my personal copyright was limited to the st copyright in > suckless. > I moved other packages, should I look at the git log of suckless.scm and > add the copyrights which apply? Yes, I think so. Thank you. -- Mathieu Lirzin
Re: [PATCH] gnu: st: Mov to terminals.scm.
e
> different functions.")
> Forget screen recording apps and blurry video. Enjoy a lightweight, purely
> text-based approach to terminal recording.")
> (license license:gpl3)))
> +
> +(define-public st
> + (package
> +(name "st")
> +(version "0.6")
> +(source
> + (origin
> + (method url-fetch)
> + (uri (string-append "http://dl.suckless.org/st/st-";
> + version ".tar.gz"))
> + (sha256
> +(base32
> + "0avsfc1qp8zvshsfjwwrkvk411jlqy58z225bsdhjkl1qc40qcc5"
> +(build-system gnu-build-system)
> +(arguments
> + '(#:tests? #f ; no tests
> + #:make-flags (list "CC=gcc"
> + (string-append "PREFIX=" %output))
> + #:phases
> + (modify-phases %standard-phases
> + (delete 'configure)
> + (add-after 'unpack 'inhibit-terminfo-install
> + (lambda _
> + (substitute* "Makefile"
> + (("\t@tic -s st.info") ""))
> + #t)
> +(inputs
> + `(("libx11" ,libx11)
> + ("libxft" ,libxft)
> + ("libxcomposite" ,libxcomposite)
> + ("compositeproto" ,compositeproto)
> + ("libxext" ,libxext)
> + ("xextproto" ,xextproto)
> + ("libxrender" ,libxrender)
> + ("fontconfig" ,fontconfig)
> + ("freetype" ,freetype)
> + ("font-liberation" ,font-liberation)))
> +(native-inputs `(("pkg-config" ,pkg-config)))
> +(home-page "http://st.suckless.org/";)
> +(synopsis "Simple terminal emulator")
> +(description
> + "St implements a simple and lightweight terminal emulator. It
> +implements 256 colors, most VT10X escape sequences, utf8, X11 copy/paste,
> +antialiased fonts (using fontconfig), fallback fonts, resizing, and line
> +drawing.")
> +(license license:x11)))
> --
> 2.9.2
Can you send an updated patch?
If nobody objects I will push this in the following days.
Thanks.
--
Mathieu Lirzin
Re: [PATCH] ui: 'package->recutils' serializes the source field.
David Craven writes: > I meant the little -s flag... > > -s, --search=REGEXPsearch in synopsis and description using REGEXP > > and I meant download, build and run manually outside of guix. > > It still sounds like that's what you are saying... ;-) oops my bad. So your summary of what I was saying was indeed correct. -- Mathieu Lirzin
Re: [PATCH] ui: 'package->recutils' serializes the source field.
David Craven writes: > If I understand you correctly, you are saying the following: > > We shouldn't display an url to a tarball that may contain unfree > software, because a user might run `guix package -s` download the > tarball from the source-uris field and build and run the code, and > accidentally run nonfree software on his computer? No, this is not what I am saying. 'guix build -S' does already provide a patched version of the tarball without the non-free stuff. So the user can't install non-free code accidentally. IIRC This behavior was introduced to comply with FSDG in order to make GuixSD a fully free distro. My point is that if we are giving a direct link to the non-patched source in our UI, the FSDG issue is the same. Sorry if I was unclear. -- Mathieu Lirzin
Re: [GSoC] Continuous integration tool à la Hydra.
Hello David, David Craven writes: > Are you already working on a package/service for guix? This would indeed be the goal, however I am not there yet. > I'd like to deploy it to my server to avoid silly mistakes > like in my last two pushes to master... > > Does it rebuild from commit individually or only HEAD? > This would be nice to check for rebase mistakes where > HEAD builds but a commit doesn't. That would make sense as an option, however the current model is simplistic and only evaluates the new HEAD commit. > Does it already support building packages for all guix > supported systems? For now, you have to modify the 'gnu-system.scm' file to your needs to achieve that. basically you need to define another "subset" case in 'gnu-system.scm' and adjust the '#:arguments' value in the job specification. > ``` > (define (local-file file) > ;; In the common case jobs will be defined relative to the repository. > ;; However for testing purpose use local gnu-system.scm instead. > (string-append (dirname (current-filename)) "/" file)) > (define hello-master > `((#:name . "guix") > (#:url . "git://git.savannah.gnu.org/guix.git") > (#:load-path . ".") > (#:file . ,(local-file "gnu-system.scm")) > (#:proc . hydra-jobs) > (#:arguments (subset . "hello")) > (#:branch . "master"))) > (list hello-master) > ``` > > Can I also define custom jobs like running guix --rounds=2 and > guix lint? Likewise. However this would require more work. :) I guess the future approach will be to define both the scheme code running on the client side and on the build (remote) side in the job specification. I mean something similar to what Guix is doing for its package definitions. The details are not defined yet. Thanks for your questions. -- Mathieu Lirzin
Re: [PATCH] ui: 'package->recutils' serializes the source field.
Alex Kost writes: > David Craven (2016-08-05 17:58 +0300) wrote: > >> * guix/ui.scm (package->recutils): Format origin. >> --- >> guix/ui.scm | 18 ++ >> 1 file changed, 18 insertions(+) >> >> >> diff --git a/guix/ui.scm b/guix/ui.scm >> index 4d1b65c..e232548 100644 >> --- a/guix/ui.scm >> +++ b/guix/ui.scm >> @@ -26,6 +26,7 @@ >> (define-module (guix ui) >>#:use-module (guix utils) >>#:use-module (guix store) >> + #:use-module (guix base32) >>#:use-module (guix config) >>#:use-module (guix packages) >>#:use-module (guix profiles) >> @@ -33,6 +34,7 @@ >>#:use-module (guix combinators) >>#:use-module (guix build-system) >>#:use-module (guix serialization) >> + #:use-module (guix git-download) >>#:use-module ((guix build utils) #:select (mkdir-p)) >>#:use-module ((guix licenses) #:select (license? license-name)) >>#:use-module ((guix build syscalls) #:select (terminal-columns)) >> @@ -878,6 +880,22 @@ WIDTH columns." >>;; Note: Don't i18n field names so that people can post-process it. >>(format port "name: ~a~%" (package-name p)) >>(format port "version: ~a~%" (package-version p)) >> + >> + (let ((uri (origin-uri (package-source p > > This will fail for some packages (for example, for 'gcc-toolchain') > because the source value can be #f, and (origin-uri #f) errors. > >> +(cond >> + ((git-reference? uri) >> +(begin > > 'begin' is not needed here. > >> + (format port "source-git-url: ~a~%" >> + (git-reference-url uri)) >> + (format port "source-git-commit: ~a~%" >> + (git-reference-commit uri)) >> + (format port "source-git-recursive: ~a~%" >> + (git-reference-recursive? uri >> + (#t > > I think using 'else' here would be more Schemey than '#t'. > >> +(format port "source-uri: ~a~%" uri >> + >> + (format port "source-hash: ~a~%" (bytevector->base32-string >> + (origin-sha256 (package-source p >>(format port "outputs: ~a~%" (string-join (package-outputs p))) >>(format port "systems: ~a~%" >>(string-join (package-transitive-supported-systems p))) > > After all I would write it like this: > > (let ((source (package-source p))) > (when (origin? source) > (let ((uri (origin-uri source))) > (cond > ((git-reference? uri) > (format port "source-git-url: ~a~%" > (git-reference-url uri)) > (format port "source-git-commit: ~a~%" > (git-reference-commit uri)) > (format port "source-git-recursive: ~a~%" > (git-reference-recursive? uri))) > (else > (format port "source-uri: ~a~%" uri > (format port "source-hash: ~a~%" > (bytevector->base32-string (origin-sha256 source) > > However, I'm not sure whether all these source things are needed to be > in the output, I would wait for other opinions. > > (I agree with you though and I would like to add the same info for Emacs > interface :-)) > > Also note that packages may have multiple sources. For example, for > 'sudo' package, the output will be: > > source-uri: (https://www.sudo.ws/sudo/dist/sudo-1.8.17p1.tar.gz > ftp://ftp.sudo.ws/pub/sudo/OLD/sudo-1.8.17p1.tar.gz) I don't have an opinion on what should be displayed or not (at least not yet). However I think there is an issue with FSDG compliance here, when upstream includes non-free stuff for the same reason that 'guix build --source PACKAGE' is required by FSDG to provide a cleaned version of the tarball. "source-uris" should point to the same thing that 'guix build -S PACKAGE' provides however in our current infrastructure this is not possible. For the same reason I think Emacs interface should not display the origin URL of those packages. I Don't know how to achieve this, maybe displaying only the URL when there is no snippet part would work even if it will remove more package source URLs than needed. WDYT? -- Mathieu Lirzin
Re: guix-0.11 help2man errors during compilation
Alex Vong writes: > Mathieu Lirzin writes: > >> Hello, >> >> Jan Synáček writes: >> >>> I'm getting strange errors: >>> >>> ... >>> HELP2MAN doc/guix-daemon.1 >>> help2man: can't get `--help' info from guix-daemon >>> Try `--no-discard-stderr' if option outputs to stderr >>> WARNING: 'help2man' is missing on your system. >>> You should only need it if you modified a dependency of a man page. >>> You may want to install the GNU Help2man package: >>> <http://www.gnu.org/software/help2man/> >>> Makefile:4893: recipe for target 'doc/guix-daemon.1' failed >>> make: [doc/guix-daemon.1] Error 127 (ignored) >>> ... >>> >>> help2man *is* present on my system. Later on, more man pages in doc/ >>> are built just fine. > > Hi, I get similar but not identical error from help2man when building > from the git repo. > > [...] > > LANGUAGE= ./pre-inst-env /bin/bash > /home/alexvong1995/scm/guix/build-aux/missing help2man --source=GNU > --info-page=guix --output="doc/guix-daemon.1" `basename "doc/guix-daemon.1" > .1` > help2man: can't get `--version' info from guix-daemon > Try `--no-discard-stderr' if option outputs to stderr > Makefile:4892: recipe for target 'doc/guix-daemon.1' failed > make[2]: [doc/guix-daemon.1] Error 64 (ignored) > make[2]: Leaving directory '/home/alexvong1995/scm/guix' > make[1]: Leaving directory '/home/alexvong1995/scm/guix' [...] > # config.log > > This file contains any messages produced by compilers while > running configure, to aid debugging if configure makes a mistake. > > It was created by GNU Guix configure 0.11.0, which was > generated by GNU Autoconf 2.69. Invocation command line was > > $ ./configure --disable-silent-rules CFLAGS=-O2 -flto CXXFLAGS=-O2 -flto > LDFLAGS=-O2 -flto > When testing with this configuration on my Debian testing system, the build fails because guix-daemon fails to build due to "-flto" options. I am using GCC 5.4. I don't know anything about link time optimizations so maybe I am overlooking something. can you print the output of: ./pre-inst-env which guix-daemon and ./pre-inst-env guix-daemon --version Thanks. -- Mathieu Lirzin
Re: guix-0.11 help2man errors during compilation
Jan Synáček writes: > On Fri, Aug 5, 2016 at 2:19 PM, Mathieu Lirzin wrote: >> Hello, >> >> Jan Synáček writes: >> >>> I'm getting strange errors: >>> >>> ... >>> HELP2MAN doc/guix-daemon.1 >>> help2man: can't get `--help' info from guix-daemon >>> Try `--no-discard-stderr' if option outputs to stderr >>> WARNING: 'help2man' is missing on your system. >>> You should only need it if you modified a dependency of a man page. >>> You may want to install the GNU Help2man package: >>> <http://www.gnu.org/software/help2man/> >>> Makefile:4893: recipe for target 'doc/guix-daemon.1' failed >>> make: [doc/guix-daemon.1] Error 127 (ignored) >>> ... >>> >>> help2man *is* present on my system. Later on, more man pages in doc/ >>> are built just fine. >> Are you building from the Git repository or the release tarball? > > I'm building from the 0.11 release tarball. Humm, this is really weird. Building from tarball is not supposed to trigger rebuilding any of the manpages which are already included. >> When you execute make again does it try to rebuild 'doc/guix-daemon.1' >> if yes, does it succeed? > > It tries again but never succeeds. > > However, after rebooting my machine, I cannot reproduce this anymore... bahhh... I will inspect what happens on Alex side then. Thank you for the details. -- Mathieu Lirzin
Re: guix-0.11 help2man errors during compilation
Hello, Jan Synáček writes: > I'm getting strange errors: > > ... > HELP2MAN doc/guix-daemon.1 > help2man: can't get `--help' info from guix-daemon > Try `--no-discard-stderr' if option outputs to stderr > WARNING: 'help2man' is missing on your system. > You should only need it if you modified a dependency of a man page. > You may want to install the GNU Help2man package: > <http://www.gnu.org/software/help2man/> > Makefile:4893: recipe for target 'doc/guix-daemon.1' failed > make: [doc/guix-daemon.1] Error 127 (ignored) > ... > > help2man *is* present on my system. Later on, more man pages in doc/ > are built just fine. I need some extra information in order to debug this. - The config.log file and the Makefile from you build directory - The output of 'make --version' and 'help2man --version' Are you building from the Git repository or the release tarball? When you execute make again does it try to rebuild 'doc/guix-daemon.1' if yes, does it succeed? Thanks, -- Mathieu Lirzin
Re: octave license is incompatible with openssl
Alex Vong writes: > John Darrington writes: > >> I would not be at all suprised if there were more incompatibilities like >> this. Ought we not have a lint rule that checks this? >> > Indeed, in the short term, we could lint for special case, such that > openssl appears as an input for an GPLv[123](+) package. > > > In the long term, we could have the following in guix. Since licenses > are scheme values. I was thinking we can have procedure like: > > (compatible? l1 l2) > > which is a reflexive and symmetric relation. Also, we might be able to > build compound licenses by: > > (dual-license lics ...) > > and > > (intersect-license lics ...) > > The 3 procedures should satisfy the following "laws": > > (compatible? l1 (dual-license lics ...)) > > if and only if > > (any (cut compatible? l1 <>) lics) > > Similarly, > > (compatible? l1 (intersect-license lics ...)) > > if and only if > > (every (cut compatible? l1 <>) lics) > > > How do everyone think? > I like the idea! -- Mathieu Lirzin
Re: ‘core-updates’ merge is a squashed commit
Hi, Andreas Enge writes: > On Thu, Aug 04, 2016 at 09:23:50AM -0400, Mark H Weaver wrote: >> I just did this. Huge thanks to Lisa Marie Maginnis, GNU sysadmin >> extraordinaire, for promptly responding to my plea for help :) > > Thanks to both of you! > >> However, we should take steps to avoid this problem in the future. The >> most recent unsigned commit on 'core-updates' was from only 3 days ago, >> by Andreas. "gnu: unison: Add input ghostscript". I'm fairly sure this >> was after we added the commit hook, so I guess the hook only applies to >> 'master'. >> So, if I understand correctly, we're currently in a state where unsigned >> commits can accidentally get pushed to other branches, making those >> branches unmergeable into 'master'. > > Sorry for that! I did not think it would be possible, and working locally > without signing every private commit is much more convenient. With gpg-agent and git properly setup, signing every local commit is not that inconvenient IME. I recommend you to give a try. ;) -- Mathieu Lirzin
Re: [GSoC] Continuous integration tool à la Hydra.
Hi, Florian Paul Schmidt writes: > On 07/29/2016 09:26 PM, Mathieu Lirzin wrote: >>> To get pkg-config, see <http://pkg-config.freedesktop.org/>. >>> See `config.log' for more details >> >> I have tested successfully with the following command on a foreign >> system: >> >> guix environment --ad-hoc automake pkg-config guile guix libgcrypt sqlite >> guile-sqlite3 >> >> Tell me if it works for you. > > Yes, that makes configure run fine. Thanks Cool. :) > This is what I get when I run it: > > fps@guix ~/cuirass [env]$ ./pre-inst-env cuirass > --specifications=tests/hello-singleton.scm --database=test.db > Cloning into 'guix'... > remote: Counting objects: 101761, done. > remote: Compressing objects: 100% (28866/28866), done. > remote: Total 101761 (delta 74214), reused 99101 (delta 72173) > Receiving objects: 100% (101761/101761), 35.86 MiB | 6.27 MiB/s, done. > Resolving deltas: 100% (74214/74214), done. > Checking connectivity... done. > HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2. > + exec autoreconf -vfi > ./bootstrap: line 5: exec: autoreconf: not found > In execvp of ./configure: No such file or directory > In execvp of make: No such file or directory > ;;; note: source file /home/fps/.cache/cuirass/guix/./guix/derivations.scm > ;;; newer than compiled > /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/guix/derivations.go > ;;; note: source file /home/fps/.cache/cuirass/guix/./guix/store.scm > ;;; newer than compiled > /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/guix/store.go > ;;; note: source file /home/fps/.cache/cuirass/guix/./guix/utils.scm > ;;; newer than compiled > /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/guix/utils.go > ;;; note: source file /home/fps/.cache/cuirass/guix/./guix/combinators.scm > ;;; newer than compiled > /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/guix/combinators.go > ;;; note: source file /home/fps/.cache/cuirass/guix/./guix/build/utils.scm > > [ more here ] > > ;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/unrtf.scm > ;;; newer than compiled > /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/unrtf.go > ;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/uucp.scm > ;;; newer than compiled > /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/uucp.go > ;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/vtk.scm > ;;; newer than compiled > /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/vtk.go > ;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/wdiff.scm > ;;; newer than compiled > /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/wdiff.go > ;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/wine.scm > ;;; newer than compiled > /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/wine.go > ;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/xfce.scm > ;;; newer than compiled > /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/xfce.go > ;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/xnee.scm > ;;; newer than compiled > /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/xnee.go > ;;; note: source file > /home/fps/.cache/cuirass/guix/./gnu/packages/yubico.scm > ;;; newer than compiled > /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/yubico.go > ;;; note: source file /home/fps/.cache/cuirass/guix/./gnu/packages/zsh.scm > ;;; newer than compiled > /gnu/store/044sj7g4gxmy9garq6ii5aips4jn6hr6-profile/share/guile/site/2.0/gnu/packages/zsh.go > evaluate 'hello-2.10.x86_64-linux': 32.563 seconds > building /gnu/store/cw502hifb3q32h2x0gl1afgzmbx9295y-hello-2.10.drv... > /gnu/store/zby49aqfbd9w9br4l52mvb3y6f9vfv22-hello-2.10 > HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2. > HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2. > HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2. > HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2. > HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2. > HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2. > HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2. > HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2. > HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2. > HEAD is now at 2fa66f4 gnu: mutt: Update to 1.6.2. >
Re: 'guix environment' as a build tool.
"Thompson, David" writes: > On Sat, Jul 30, 2016 at 10:05 PM, Mathieu Lirzin wrote: >> l...@gnu.org (Ludovic Courtès) writes: >> >>> Mathieu Lirzin skribis: >>> >>>> I have tested successfully with the following command on a foreign >>>> system: >>>> >>>> guix environment --ad-hoc automake pkg-config guile guix libgcrypt >>>> sqlite guile-sqlite3 >>>> >>>> Tell me if it works for you. >>>> >>>>> How about including a guix package definition then we can easily build >>>>> it assuming "we" know how to do out-of-guix-tree package building :) >>>> >>>> It would indeed be nice to provide an easy way for Guix users to install >>>> Cuirass. IMHO package definitions meant as a development build tool is >>>> confusing and should be avoided. Nonetheless, I think it is useful to >>>> document the previous 'guix environment ...' command in the README. >>> >>> What about providing a ‘guix.scm’ file that people could pass to ‘guix >>> environment -l’ (instead of typing the long command above), and to ‘guix >>> package -f’ (info "(guix) Invoking guix package")? >> >> 'guix environment -l' uses a package definition. To me this abstraction >> doesn't fit well in a development context: > > It *does* fit well. This use-case is why I wrote 'guix environment' > in the first place. Obviously I disagree. >> - the origin hash doesn't make sense. > > You don't need one. Use local-file for the source field. I would be happy to, however I vaguely remember trying this without success for Mcron. Do you have an example to provide? >> - packages already included in Guix have redundant description and synopsis. > > I don't understand what this means. > >> - package definitions rely on Guix internals. > > The package API rarely changes in practice. This is relative, IME packages moving across modules is not an exception. >> In fact what 'guix.scm' contains feels more like a "debian" directory or >> a "PACKAGE.spec" file on steroid because of the "guix environment -l" >> feature which derives from it but doesn't appear as first class. >> >> An idea that I like better and is less invasive, would be to complement >> bootstrap scripts with: >> >> ./bootstrap --with-guix >> >> This command would: >> >> - generate a guix-env script that wraps 'guix environment ...' if it >> doesn't exist. >> - Invoke ./guix-env >> - Invoke autoreconf -vfi >> >> if the user wants to enter this environment Later it will have to invoke >> './guix-env'. > > This just makes things more inconvenient and limits potential utility. > You would lose the ability to tweak the dependency graph with custom > package recipes. > I do this frequently in my projects that use bleeding edge features > of other software that may not even have an official release yet. Since this script is supposed to be wrapper around 'guix environment' I don't understand how it could limit anything 'guix environment' could do? > Also, with a package file, Guix users can install the development > snapshot with 'guix package -f' or simply build it with 'guix build > -f'. I am not sure what you mean by "development snapshot". If you an arbitrary timely chosen commit like what is done for Haunt: (origin (method git-fetch) (uri (git-reference (url "git://dthompson.us/haunt.git") (commit "f0a7c2b14a201448432d3564d851ee0686d5b1b1"))) (sha256 (base32 "1dnzsw18blhr8admw48zbl3ilz3iiqmb149i37y820h0imqfli0v" This is not useful for me. In most case I want 'guix build -f' to build the current commit from the local repository. If 'local-file' can work then this is fine, but I have never achieved the expected result. >> Some interesting things could be done beyond this, for example by using >> per repository profiles that would save development environments. This >> would allow developpers to easily use different setups. > > 'guix environment' already serves this purpose. > I do want to extend 'guix environment' with a --save flag that will > register the profile it generates as a GC root so that it can be saved > for future sessions so that the environment doesn't need to be rebuilt > every time the user upgrades Guix. That would be nice. > Hopefully this clears things up Maybe I am misinterpreting, but this read a bit patronizing. No need to say that if this is the case I don't appreciate much. -- Mathieu Lirzin
'guix environment' as a build tool. (was: [GSoC] Continuous integration tool à la Hydra.)
l...@gnu.org (Ludovic Courtès) writes: > Mathieu Lirzin skribis: > >> I have tested successfully with the following command on a foreign >> system: >> >> guix environment --ad-hoc automake pkg-config guile guix libgcrypt sqlite >> guile-sqlite3 >> >> Tell me if it works for you. >> >>> How about including a guix package definition then we can easily build >>> it assuming "we" know how to do out-of-guix-tree package building :) >> >> It would indeed be nice to provide an easy way for Guix users to install >> Cuirass. IMHO package definitions meant as a development build tool is >> confusing and should be avoided. Nonetheless, I think it is useful to >> document the previous 'guix environment ...' command in the README. > > What about providing a ‘guix.scm’ file that people could pass to ‘guix > environment -l’ (instead of typing the long command above), and to ‘guix > package -f’ (info "(guix) Invoking guix package")? 'guix environment -l' uses a package definition. To me this abstraction doesn't fit well in a development context: - the origin hash doesn't make sense. - packages already included in Guix have redundant description and synopsis. - package definitions rely on Guix internals. In fact what 'guix.scm' contains feels more like a "debian" directory or a "PACKAGE.spec" file on steroid because of the "guix environment -l" feature which derives from it but doesn't appear as first class. An idea that I like better and is less invasive, would be to complement bootstrap scripts with: ./bootstrap --with-guix This command would: - generate a guix-env script that wraps 'guix environment ...' if it doesn't exist. - Invoke ./guix-env - Invoke autoreconf -vfi if the user wants to enter this environment Later it will have to invoke './guix-env'. Some interesting things could be done beyond this, for example by using per repository profiles that would save development environments. This would allow developpers to easily use different setups. WDYT? -- Mathieu Lirzin
Re: [GSoC] Continuous integration tool à la Hydra.
Hello, Florian Paul Schmidt writes: > On 07/25/2016 11:36 PM, Ludovic Courtès wrote: > >>> For those willing to follow my work, a Git repository is available here: >>> >>> https://notabug.org/mthl/cuirass >> >> … and the README has instructions on how to run it. If anyone has spare >> CPU cycles, run Cuirass, ‘guix publish’, and share. :-) > > Sorry, if this mail comes around twice. Thunderbird crashed :( > > Sadly the instructions to build it are a bit unclear. I tried: > > fps@guix ~/cuirass$ guix environment --ad-hoc gcc gcc:lib automake guix > guile > guix environment: warning: ambiguous package specification `guile' > guix environment: warning: choosing guile-2.0.11 from > gnu/packages/guile.scm:131:2 > fps@guix ~/cuirass [env]$ > GUILE_LOAD_PATH=$GUILE_LOAD_PATH:/home/fps/guix/ ./configure > > > > > checking for a BSD-compatible install... > /run/current-system/profile/bin/install -c > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... > /run/current-system/profile/bin/mkdir -p > checking for gawk... gawk > checking whether make sets $(MAKE)... no > checking whether make supports nested variables... no > checking whether make supports nested variables... (cached) no > checking build system type... x86_64-unknown-linux-gnu > checking host system type... x86_64-unknown-linux-gnu > checking for pkg-config... no > checking for GUILE... no > configure: error: in `/home/fps/cuirass': > configure: error: The pkg-config script could not be found or is too > old. Make sure it > is in your PATH or set the PKG_CONFIG environment variable to the full > path to pkg-config. > > Alternatively, you may set the environment variables GUILE_CFLAGS > and GUILE_LIBS to avoid the need to call pkg-config. > See the pkg-config man page for more details. > > To get pkg-config, see <http://pkg-config.freedesktop.org/>. > See `config.log' for more details I have tested successfully with the following command on a foreign system: guix environment --ad-hoc automake pkg-config guile guix libgcrypt sqlite guile-sqlite3 Tell me if it works for you. > How about including a guix package definition then we can easily build > it assuming "we" know how to do out-of-guix-tree package building :) It would indeed be nice to provide an easy way for Guix users to install Cuirass. IMHO package definitions meant as a development build tool is confusing and should be avoided. Nonetheless, I think it is useful to document the previous 'guix environment ...' command in the README. Thank you for your feedback. -- Mathieu Lirzin
[PATCH] gnu: Add tint2.
* gnu/packages/xdisorg.scm (tint2): New variable.
---
gnu/packages/xdisorg.scm | 49 ++--
1 file changed, 47 insertions(+), 2 deletions(-)
diff --git a/gnu/packages/xdisorg.scm b/gnu/packages/xdisorg.scm
index 485bbc4..a3c6c7d 100644
--- a/gnu/packages/xdisorg.scm
+++ b/gnu/packages/xdisorg.scm
@@ -4,7 +4,7 @@
;;; Copyright © 2014 Eric Bavier
;;; Copyright © 2014, 2015, 2016 Alex Kost
;;; Copyright © 2013, 2015 Ludovic Courtès
-;;; Copyright © 2015 Mathieu Lirzin
+;;; Copyright © 2015, 2016 Mathieu Lirzin
;;; Copyright © 2015 Alexander I.Grafov
;;; Copyright © 2015 Andy Wingo
;;; Copyright © 2015 xd1le
@@ -48,7 +48,7 @@
#:use-module (gnu packages gettext)
#:use-module (gnu packages gl)
#:use-module (gnu packages glib)
- #:use-module (gnu packages gnome) ;for libgudev
+ #:use-module (gnu packages gnome)
#:use-module (gnu packages ncurses)
#:use-module (gnu packages perl)
#:use-module (gnu packages python)
@@ -976,3 +976,48 @@ connectivity of the X server running on a particular @code{DISPLAY}.")
applications you regularily use and also allows you to search for an application
by name.")
(license license:expat)))
+
+(define-public tint2
+ (package
+(name "tint2")
+(version "0.12.11")
+(source (origin
+ (method url-fetch)
+ (uri (string-append "https://gitlab.com/o9000/"; name
+ "/repository/archive.tar.gz?ref=" version))
+ (file-name (string-append name "-" version ".tar.gz"))
+ (sha256
+ (base32
+"0dv7zaj2ahnfclnwnwcz9arrvzxn65yy29z7fqdgifdh3jk1kl2h"
+(build-system cmake-build-system)
+(arguments
+ '(#:tests? #f ;no test target
+ #:phases
+ (modify-phases %standard-phases
+ (add-after 'unpack 'fix-installation-prefix
+ (lambda _
+ (substitute* "CMakeLists.txt"
+ (("/etc") "${CMAKE_INSTALL_PREFIX}/etc")))
+(inputs
+ `(("gtk+" ,gtk+-2)
+ ("imlib2" ,imlib2)
+ ("librsvg" ,librsvg)
+ ("libxcomposite" ,libxcomposite)
+ ("libxdamage" ,libxdamage)
+ ("libxft" ,libxft)
+ ("libxinerama" ,libxinerama)
+ ("libxrandr" ,libxrandr)
+ ("startup-notification" ,startup-notification)))
+(native-inputs
+ `(("gettext" ,gnu-gettext)
+ ("pkg-config" ,pkg-config)))
+(home-page "https://gitlab.com/o9000/tint2";)
+(synopsis "Lightweight taskbar")
+(description "Tint2 is a simple panel/taskbar made for modern X window
+managers. It was specifically made for Openbox but it should also work with
+other window managers (GNOME, KDE, XFCE etc.).
+
+The taskbar includes transparency and color settings for the font, icons,
+border, and background. It also supports multihead setups, customized mouse
+actions, a built-in clock, a battery monitor and a system tray.")
+(license license:gpl2)))
Re: [PATCH] gnu: password-store: Wrap PATH.
Alex Griffin writes: > On Fri, Jul 29, 2016, at 09:02 AM, Thompson, David wrote: >> Sorry I'm late, but I don't think this is the right fix. Sorry for not letting you the time to respond. >> Wrapping programs should only be considered after other options are >> exhausted. The correct fix is to patch the source directly to refer >> to executables by their absolute path. Why wasn't it done this way? > > Mostly because it would be a lot of on-going work every time the package > is updated. As a shell script, it invokes an external tool nearly every > other line. If you look at the discussion that happened in February when > the package was first added [1], Jessica (the original packager) was > really discouraged by the prospect of patching every invocation of an > external tool. She also tried to submit changes upstream so that kind of > work wouldn't be necessary, but upstream wasn't very receptive to the > idea. In the end, the package was just committed to Guix in a broken > state. > > Another approach I considered was adding a bunch of shell aliases to the > top of the script pointing to the Guix store. That makes the problem a > lot more tractable than replacing every external invocation, but it's > still kinda complicated and it still requires finding every single > program that gets called and keeping it up to date with new releases. So > even if all upstream does is use another program from coreutils, the fix > would be out-of-date again. > > [1]: https://lists.gnu.org/archive/html/guix-devel/2016-02/msg01310.html This makes sense to me. -- Mathieu Lirzin
Re: [PATCH] gnu: password-store: Wrap PATH.
Hello,
Alex Griffin writes:
> On Thu, Jul 28, 2016, at 07:20 PM, Alex Griffin wrote:
>
> From 74b838fea52293386169299881cdd7cfefff7f4d Mon Sep 17 00:00:00 2001
> From: Alex Griffin
> Date: Thu, 28 Jul 2016 19:06:10 -0500
> Subject: [PATCH] gnu: password-store: Wrap PATH.
>
> * gnu/packages/password-utils.scm (password-store):
> [arguments]: Wrap PATH more thoroughly.
> [native-inputs]: Move getopt to inputs.
> [inputs]: Add sed & alphabetize packages.
^^
Indentation and formatting changes can be omitted in commit log.
> ---
> gnu/packages/password-utils.scm | 33 -
> 1 file changed, 16 insertions(+), 17 deletions(-)
>
> diff --git a/gnu/packages/password-utils.scm b/gnu/packages/password-utils.scm
> index a03214a..497717f 100644
> --- a/gnu/packages/password-utils.scm
> +++ b/gnu/packages/password-utils.scm
> @@ -6,6 +6,7 @@
> ;;; Copyright © 2016 Jessica Tallon
> ;;; Copyright © 2016 Andreas Enge
> ;;; Copyright © 2016 Lukas Gradl
> +;;; Copyright © 2016 Alex Griffin
> ;;;
> ;;; This file is part of GNU Guix.
> ;;;
> @@ -266,27 +267,25 @@ any X11 window.")
> '(#:phases
> (modify-phases %standard-phases
> (delete 'configure)
> - (add-after
> - ;; The script requires 'getopt' at run-time, and this allows
> - ;; the user to not install the providing package 'util-linux'
> - ;; in their profile.
> - 'unpack 'patch-path
> - (lambda* (#:key inputs outputs #:allow-other-keys)
> -(let ((getopt (string-append (assoc-ref inputs "getopt")
> - "/bin/getopt")))
> - (substitute* "src/password-store.sh"
> -(("GETOPT=\"getopt\"")
> - (string-append "GETOPT=\"" getopt "\"")))
> - #t
> + (add-after 'install 'wrap-path
> + (lambda* (#:key inputs outputs #:allow-other-keys)
> + (let* ((out (assoc-ref outputs "out"))
> +(path (map (lambda (pkg)
> + (string-append (assoc-ref inputs pkg)
> "/bin"))
> + '("coreutils" "getopt" "git" "gnupg" "pwgen"
> + "sed" "tree" "which" "xclip"
> + (wrap-program (string-append out "/bin/pass")
> + `("PATH" ":" prefix (,(string-join path ":"
'let*' can safely be replaced by 'let' here.
> #:make-flags (list "CC=gcc" (string-append "PREFIX=" %output))
> #:test-target "test"))
> -(native-inputs `(("getopt" ,util-linux))) ; getopt for the tests
> -(inputs `(("gnupg" ,gnupg)
> - ("pwgen" ,pwgen)
> - ("xclip" ,xclip)
> +(inputs `(("getopt" ,util-linux)
>("git" ,git)
> + ("gnupg" ,gnupg)
> + ("pwgen" ,pwgen)
> + ("sed" ,sed)
>("tree" ,tree)
> - ("which" ,which)))
> + ("which" ,which)
> + ("xclip" ,xclip)))
> (home-page "http://www.passwordstore.org/";)
> (synopsis "Encrypted password manager")
> (description "Password-store is a password manager which uses GnuPG to
Pushed in commit 61201e46a72b715e1a38ce56932c3f4f2d3885b4.
Thanks.
--
Mathieu Lirzin
Re: [PATCH 2/2] gnu: atlas: Use cpupower in description.
Hello, ng0 writes: > Mathieu Lirzin writes: > >> Tobias Geerinckx-Rice writes: >> >>> Ludo', >>> >>> On 2016-07-19 23:00, l...@gnu.org wrote: >>>> Applied, thanks! >>> >>> Thanks! I didn't know about @example. >>> >>> It seems like some Texinfo syntax is encouraged (like @command), but >>> not the full set (package descriptions are full of abbreviations, >>> but no @abbr or @acronym anywhere). Is this by design? >> >> Nope it is not by design, the Guile (texinfo ...) modules just don't >> implement these commands from GNU Texinfo, but should indeed. >> >> -- >> Mathieu Lirzin >> > > Is there a feature request / bug we could file somewhere on this? I > don't know what the upstream of Guile texinfo is, but it reads like it > should be extended. Guile texinfo is maintained in Guile itself. You can send a bug report to . Thanks! -- Mathieu Lirzin
Re: Call for screencasts!
l...@gnu.org (Ludovic Courtès) writes: > l...@gnu.org (Ludovic Courtès) skribis: > >> I’d like a video of at most 5 minutes to put on the home page that would >> showcase, for example (with explanations in English; bonus points if you >> have a good mic and are a native speaker ;-)): >> >> 1. The usual ‘guix package’ commands; >> 2. the Emacs interface, briefly (like the generation diff); >> 3. ‘guix environment’, including with ‘--container’; >> 4. ‘guix system vm’ and the declarative OS configuration. > > I tried to extend my skill set, and made this, ahem, wonderful video: > > http://web.fdn.fr/~lcourtes/tmp/guix-demo.ogv (4 MiB) > http://web.fdn.fr/~lcourtes/tmp/guix-demo.gif (24 MiB!) Amazing! > It’s 1mn15s long and only shows #1, but I thought it’s a good start as > something to replace the 50mn video currently on the front page. > > What do people think? This is definitely a good idea. -- Mathieu Lirzin
Re: [GSoC] Continuous integration tool à la Hydra.
Hello, l...@gnu.org (Ludovic Courtès) writes: > Mathieu Lirzin skribis: > [...] >> CREATE TABLE Specifications ( >> idINTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, >> repo_name TEXT NOT NULL, >> url TEXT NOT NULL, >> load_path TEXT NOT NULL, >> file TEXT NOT NULL, >> proc TEXT NOT NULL, >> arguments TEXT NOT NULL, >> -- The following columns are optional. >> branchTEXT, >> tag TEXT, >> revision TEXT >> ); >> >> CREATE TABLE Evaluations ( >> derivationTEXT NOT NULL PRIMARY KEY, >> job_name TEXT NOT NULL, >> specification INTEGER NOT NULL, >> FOREIGN KEY (specification) REFERENCES Specifications (id) >> ); > > An evaluation leads to several derivations (for Guix, roughly one > derivation per package and per system type), but the table above seems > to suggest that each evaluation is mapped to only one derivation? In my "confused" mind each derivation was considered an individual evaluation. But as you pointed out this makes more sense to decouple those. Fixed in commit d493a58823aed8c556bf795d02207e57718b96c9 Thanks, -- Mathieu Lirzin
Re: Ricardo Wurmus appointed co-maintainer
l...@gnu.org (Ludovic Courtès) writes: > I’m happy to announce that Ricardo Wurmus has just been appointed by the > GNU overseers to join me as co-maintainer of GNU Guix. Congratulations Ricardo! -- Mathieu Lirzin
Re: [GSoC] Continuous integration tool à la Hydra.
Hello Guix! Here is a third update on my GSoC project after the second month. As a reminder, Hydra (https://nixos.org/hydra/) is a Nix-based continuous build system which is used by Guix to compile packages on different platforms and to distribute packages substitutes. The aim of this project is to replace Hydra with a more integrated software written in Guile, named “Cuirass”. Since my second update I have first fixed a major bug. When building different branches of Guix and evaluating package derivations the results were always the same. The issue was that the evaluations were happening in the same Guile process which does not play well with module changes. To fix that I have used a separate process + pipe to get the evaluation results. In the last update, I have introduced usage of SRFI-9 records for specifications, jobs, and builds. While they are nice to organize data, they have major drawbacks: - not flexible when you want to informally create a container. - require serialization when passing them throught pipes. For those reasons I have switched to good ol' alists, which are flexible, persistant, directly readable and don't require messing with load paths. The downside is of course that there is no compile time checks when manipulating data. As stated in my last update. I have been working on storing data in a database. For that I have decided to use Guile-sqlite3. The principal efforts have consist of using an external schema file and design it. I have come up with this, but this will likely evolve in the future: --8<---cut here---start->8--- CREATE TABLE Specifications ( idINTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, repo_name TEXT NOT NULL, url TEXT NOT NULL, load_path TEXT NOT NULL, file TEXT NOT NULL, proc TEXT NOT NULL, arguments TEXT NOT NULL, -- The following columns are optional. branchTEXT, tag TEXT, revision TEXT ); CREATE TABLE Evaluations ( derivationTEXT NOT NULL PRIMARY KEY, job_name TEXT NOT NULL, specification INTEGER NOT NULL, FOREIGN KEY (specification) REFERENCES Specifications (id) ); CREATE TABLE Builds ( id INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, derivation TEXT NOT NULL, log TEXT NOT NULL, output TEXT, -- NULL if build failed FOREIGN KEY (derivation) REFERENCES Evaluations (derivation) ); --8<---cut here---end--->8--- The next step will be to continue improving the database communication, and start looking how to implement the HTTP API. For those willing to follow my work, a Git repository is available here: https://notabug.org/mthl/cuirass Everyone is of course welcome to provide any feedback. Thanks. -- Mathieu Lirzin
Re: Review process
Alex Kost writes: > Mathieu Lirzin (2016-07-23 12:51 +0300) wrote: > >> Alex Kost writes: >> >>> Pjotr Prins (2016-07-23 05:24 +0300) wrote: >>> >>>> Thanks Ludo. As it stands I am no longer submitting packages to ML. I >>>> did my utmost to make the package lean and clean. This package is not >>>> going in. >>>> >>>> But, I suggest you listen. I know at least 4 people here who say they >>>> have trouble submitting to Guix. Good people. >>> >>> 5 including me :-) I always feel big inconveniences sending patches, and >>> I don't like that the development happens on mailing list. However >>> unlike Pjotr and Jookia I think it's my problem, not the one of the Guix >>> community. >>> >>> I just wrote this because I'm almost sure that some day I will maintain >>> emacs interface separately from Guix again. I've been regretting all >>> the time that it became a part of Guix. >> >> I am interested to know what do you miss from that the period you were >> maintaining it separately? > > Oh, this is easy: if I maintain something myself, I don't ask anyone, I > just commit whatever seems appropriate to me, and that's it. When I > send patches for emacs UI to the mailing list, it's like I ask > permissions to modify a part of code I wrote. Sure, I understand this can feel frustrating. > Also I always have a bad feeling that I load Ludovic (who is the only > person reviewing these patches) with a useless additional work. I am confident that Ludovic doesn't think of your patches that way. > Finally, I feel like I clog the mailing list with my patches. Sometimes > I want to make some small change, but then I think: «Ah, it's not so > big, no one will ever notice it anyway, so I wouldn't bother people with > it.» (although recently myglc2 noticed several such things :-)) Maybe you could view your patches for emacs UI has a buffer with an "LGTM" default that you can push for example 1 week later. It gives others a chance to comment on potential controversial changes and gives you a chance to improve them, without feeling that you are asking permission. What do others think? Even if I am not very active in reviewing/commenting your patches, I appreciate the fact that Emacs UI is included in Guix source tree because it feels integrated and is ready to hack for any Guix contributor. I hope this will continue. Thanks for sharing your thoughts. -- Mathieu Lirzin
Re: A registry for distributed sources and binaries
Hi, Mark H Weaver writes: > Pjotr Prins writes: > >> How about the following: >> >> 1. Separate from the GNU project, we create a number of registries of >>online git repos without opinion (i.e., anything goes, it is up to >>the authors). A registry can contain the work of multiple packages >>and multiple authors. >> >> 2. Each repo in the registry can create package definitions online > > The major problem with this proposal is that, to the extent it became > popular, it would drastically reduce the freedom we have to change Guix > itself. We would need to start considering whether our changes might > break externally maintained packages. A large proportion of our > internal procedures and macros would effectively become a public API. > We would no longer be able to freely make changes to the way packages > are specified, or make incompatible changes to the procedures and macros > used in package definitions on the client or build sides. We would be > greatly constrained in our ability to make changes to the default phases > in our build systems. > > Our core packages and most of our library packages would also > effectively be part of this API. We would no longer be able to freely > do things like split packages into smaller pieces or multiple outputs. > > Long ago, the Linux developers made a conscious decision to not support > out-of-tree drivers, for much the same reasons. Many times over the > years, they have made changes to their internal APIs that required > corresponding changes to a large number of drivers. As a result, they > have been able to keep their internal interfaces clean and free of > backward-compatibility cruft. > > It's crucially important to the future vitality of this project that we > retain our freedom to evolve the design of Guix, the way packages are > specified in Guix, as well as the set of core packages. These freedoms > will be drastically curtailed if we support a decentralized system of > externally-managed repositories. Therefore, we must not do this. > > What do other people think? I fully agree with everything you said. When acknowledging all the consequences of providing a public API for package definitions, the main goal of lowering the barrier to entry is missed because everything becomes more complex. -- Mathieu Lirzin
Re: Review process
Alex Kost writes: > Pjotr Prins (2016-07-23 05:24 +0300) wrote: > >> Thanks Ludo. As it stands I am no longer submitting packages to ML. I >> did my utmost to make the package lean and clean. This package is not >> going in. >> >> But, I suggest you listen. I know at least 4 people here who say they >> have trouble submitting to Guix. Good people. > > 5 including me :-) I always feel big inconveniences sending patches, and > I don't like that the development happens on mailing list. However > unlike Pjotr and Jookia I think it's my problem, not the one of the Guix > community. > > I just wrote this because I'm almost sure that some day I will maintain > emacs interface separately from Guix again. I've been regretting all > the time that it became a part of Guix. I am interested to know what do you miss from that the period you were maintaining it separately? -- Mathieu Lirzin
