bug#22981: guix-edit does not find git checkout directory
myglc2 (2016-03-13 05:00 +0300) wrote: [...] > Thank you for this great summary. This list + the post you referenced > make me feel better that I am taking so long to figure Guix out ;) > > OTOH, guix as more state-full than I had hoped ;( > > I suggest that you think of it this way: You are running an easter egg > hunt (I hope this is an OK analogy). You have awesome eggs (No kidding, > I can attest that the Guix eggs are truly awesome). When the children > find the eggs they will be truly happy. But the eggs are hard to > find. If the children don't find the eggs they will not be happy! Worse > yet, your eggs will be wasted! So ... make it easy for children to find > your eggs. I don't know what an "easter egg hunt" is, but I think I get your analogy. > You probably already thought of this: Can guix be made easier to use by > converting some of the state-full guix configuration into guix recipe > inputs? Sorry, my knowledge in English language is not enough to understand this question. Could you explain what "state-full" means? -- Alex
bug#22970: guix edit mutt -- not working
Hello Alex, I have followed your recommendation, and mutt is working modified. However, now I get useless error messages. And I can imagine, if I have modified 10 packages, that I would get 10x that much of error messages. warning: collision encountered: /gnu/store/xxzgai9khdfhk70p06vs6akrarzph9r2-my-mutt-1.5.24/share/man/man1/mutt.1.gz /gnu/store/vh7ghk1xlrn4crshqrdygp5573aipk44-mutt-1.5.24/share/man/man1/mutt.1.gz warning: arbitrarily choosing /gnu/store/xxzgai9khdfhk70p06vs6akrarzph9r2-my-mutt-1.5.24/share/man/man5/muttrc.5.gz warning: collision encountered: /gnu/store/xxzgai9khdfhk70p06vs6akrarzph9r2-my-mutt-1.5.24/bin/mutt /gnu/store/vh7ghk1xlrn4crshqrdygp5573aipk44-mutt-1.5.24/bin/mutt warning: arbitrarily choosing /gnu/store/xxzgai9khdfhk70p06vs6akrarzph9r2-my-mutt-1.5.24/bin/mutt warning: collision encountered: /gnu/store/xxzgai9khdfhk70p06vs6akrarzph9r2-my-mutt-1.5.24/bin/flea /gnu/store/vh7ghk1xlrn4crshqrdygp5573aipk44-mutt-1.5.24/bin/flea Let me stop with copy and paste, because there are many more lines like that. Maybe it is design of guix package manager, maybe it is my fault. I understood that I can change definitions for guix packages, and such would be installed. There shall be no warnings like this. I do intend to make about 5-10 packages for system I use, and I worry about future warning messages, it will be like 3-4 screens, making guix package manager not user-friendly. I would not see real errors. On Fri, Mar 11, 2016 at 01:48:39PM +0300, Alex Kost wrote: > Jean Louis (2016-03-10 22:34 +0300) wrote: > > > Hello Andreas, > > > > I have now 2 files in gnu/guix/packages/*.scm, for mutt and postgresql: > > and now I get each time on running guix, following: > > > > guix package: warning: failed to load '(databases)': > > ERROR: no code for module (databases) > > guix package: warning: failed to load '(mutt)': > > ERROR: no code for module (mutt) > > > > because 2 files are: databases.scm and mutt.scm > > > > I have already installed mutt, with changes, and it works. On the end of > > file there is word "mutt". Similar for PostgreSQL, only it did not yet > > compile. > > > > Now I get a feeling, if I have 20 files to change or adapt to my system, > > I will get 20 warnings by each run of guix package manager. > > > > Somehow it does not feel right. > > > > It would be more logical to have GUIX_PACKAGE_PATH plus one separate > > file where some modified or user related packages are listed, instead of > > having the package name on the end of *.scm file. > > I agree, using GUIX_PACKAGE_PATH is such a nice way to keep your own > packages. I don't understand why Andreas recommended to use "guix > package -f". I think it is suitable to build some development > "guix.scm" file (not related, but see ¹). But for user packages, I > think keeping them in GUIX_PACKAGE_PATH directories is a much better > solution. > > I also don't recommend to use the same /gnu/packages/*.scm structure, as > there may be problems with this. For example, you copied > /gnu/packages/databases.scm to your GUIX_PACKAGE_PATH dir and modified > some package in it. Then you have to follow the changes in this file > made in Guix, and update your local databases.scm accordingly all the > time. > > So if you want to keep all your packages in a single file, you can make > "/my-guix-packages.scm", add to GUIX_PACKAGE_PATH, > and that's it! This "my-guix-packages.scm" file will look like this: > > (define-module (my-guix-packages) > #:use-module (guix packages) > #:use-module (guix download) > #:use-module (guix utils) > #:use-module (gnu packages mail)) > > (define-public my-mutt > (package > (inherit mutt) > (name "my-mutt") > (arguments > (substitute-keyword-arguments (package-arguments mutt) >((#:configure-flags cf) > `(cons "--enable-hcache" ,cf > (synopsis (string-append (package-synopsis mutt) > " (configured with --enable-hcache)" > > And all guix commands will find packages in this file, for example you > can do: "guix package -i my-mutt". Try it!
bug#22970: guix edit mutt -- not working
On Sun, 13 Mar 2016 11:47:04 +0100 Jean Louis wrote: > Hello Alex, > > I have followed your recommendation, and mutt is working modified. > However, now I get useless error messages. And I can imagine, if I have > modified 10 packages, that I would get 10x that much of error messages. > > warning: collision encountered: > /gnu/store/xxzgai9khdfhk70p06vs6akrarzph9r2-my-mutt-1.5.24/bin/mutt > /gnu/store/vh7ghk1xlrn4crshqrdygp5573aipk44-mutt-1.5.24/bin/mutt > Now that you have my-mutt installed you can remove mutt -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted pgpmDDS10AIig.pgp Description: OpenPGP digital signature
bug#22990: Grafts leads to inefficient substitute info retrieval
Alex Kost skribis:
> Ludovic Courtès (2016-03-11 19:52 +0300) wrote:
>
>> As of right now (v0.9.0-2007-g66a30a3), ‘graft-derivation’ works either by:
>>
>> 1. Fetching substitute info about the things being built so that it
>> can determine its references, which in turns allows it to determine
>> whether they need to be grafted.
>>
>> 2. Building stuff, as a last resort, so that it can determine its
>> references.
>
> I noticed that #1 is happening even with --no-substitutes option. Is it
> intended?
Not really, but I see this is because ‘substitutable-path-info’ (called
from ‘references/substitutes’, called from ‘graft-derivation’) works
regardless of whether substitutes are enabled:
--8<---cut here---start->8---
scheme@(guile-user)> ,use(guix)
scheme@(guile-user)> (define s (open-connection))
scheme@(guile-user)> (set-build-options s #:use-substitutes? #f)
$2 = #t
scheme@(guile-user)> (valid-path? s
"/gnu/store/qf2lm7jpiiyygxz8zq0r1ca1fazv6smn-mutt-1.5.24")
$3 = #f
scheme@(guile-user)> (substitutable-path-info s
'("/gnu/store/qf2lm7jpiiyygxz8zq0r1ca1fazv6smn-mutt-1.5.24"))
$4 = (#< path:
"/gnu/store/qf2lm7jpiiyygxz8zq0r1ca1fazv6smn-mutt-1.5.24" deriver:
"/gnu/store/jcl9c3w463xa2g963q5a60rrd97y1g28-mutt-1.5.24.drv" refs:
("/gnu/store/3gmzl5jpk700hqyr8p3kfg0vgcnw8d97-libassuan-2.4.2"
"/gnu/store/b02lmk67jq1vcflk2m2bwzc8gmwmndqp-ncurses-6.0"
"/gnu/store/d3xdc2w87yw3raafwb9q34gxx4xqci8k-cyrus-sasl-2.1.26"
"/gnu/store/pkasxagsa4z4viscfpl6sjszmdmwncl1-gcc-4.9.3-lib"
"/gnu/store/qf2lm7jpiiyygxz8zq0r1ca1fazv6smn-mutt-1.5.24"
"/gnu/store/qvx4q6lbwi4s3cwr8wqaa7kcva0a5c4b-openssl-1.0.2f"
"/gnu/store/sb40mddkia0brc814xkbnhxccfm32q3a-gpgme-1.6.0"
"/gnu/store/sgzfawy95pfn7nsw3xvmca58llm5zzbc-glibc-2.22"
"/gnu/store/x2p2biyybcb2wac77qz9468asc5fm48i-perl-5.22.1"
"/gnu/store/x8dmdlrn5qn0wrbcnngj55y3ab73h0pp-bash-4.3.42"
"/gnu/store/zpxg45dq67psrn4wmfk4l635h0si8q63-libgpg-error-1.21") dl-size: 0
nar-size: 6661016>)
--8<---cut here---end--->8---
However, substitutes are not downloaded, so in this regard
--no-substitutes is honored.
Ludo’.
bug#21806: TeX Live: missing biber executable
Ludovic Courtès writes: > Sure, no problem. I just wanted to know if you had given up or stumbled > upon a problem where we could help. :-) I think I am nearly there, I have packaged all biber dependencies, but I still have some trouble with tests and runpath validation. I'd like to send the patch to the list see if someone can help me. From the history it looks like you operate on a 'one package, one commit' basis, is that right? Thanks, Clément
bug#22981: guix-edit does not find git checkout directory
Alex Kost writes: > myglc2 (2016-03-13 05:00 +0300) wrote: > > [...] >> You probably already thought of this: Can guix be made easier to use by >> converting some of the state-full guix configuration into guix recipe >> inputs? > > Sorry, my knowledge in English language is not enough to understand this > question. Could you explain what "state-full" means? NP. I may have caused a problem by miss-spelling "stateful", which I meant this way ... "The output of a digital circuit or computer program at any time is completely determined by its current inputs and its state." Ref: https://en.wikipedia.org/wiki/State_(computer_science) Guix is "stateful" because, to use a git checkout, I have to set "state" variables like ... (setq guix-directory "/home/glc/src/guix") (let ((dir "~/dev/guix/emacs")) (add-to-list 'load-path dir) (setq guix-load-path dir) (require 'guix-init nil t)) '(safe-local-variable-values (quote ((bug-reference-bug-regexp . "") (custom-set-faces /home/glc/.config/guix/latest’ -> ‘../../src/guix' /root/.config/guix/latest’ -> ‘/home/glc/src/GUI’ Guix would be less stateful (AKA more "stateless") if instead I could put something like ... (guix (#:use-git #t) (#:git-directory:"~/src/guix")) ... in user.scm and do 'guix package -m user.scm' ;)
bug#21806: TeX Live: missing biber executable
Clément skribis: > Ludovic Courtès writes: > >> Sure, no problem. I just wanted to know if you had given up or stumbled >> upon a problem where we could help. :-) > > I think I am nearly there, I have packaged all biber > dependencies, but I still have some trouble with tests and > runpath validation. I'd like to send the patch to the list see > if someone can help me. Sure, it’s a good idea. > From the history it looks like you operate on a 'one package, one > commit' basis, is that right? Exactly. Thank you! Ludo’.
bug#22981: guix-edit does not find git checkout directory
myglc2 skribis: > Guix is "stateful" because, to use a git checkout, I have to set "state" > variables like ... > > (setq guix-directory "/home/glc/src/guix") > > (let ((dir "~/dev/guix/emacs")) > (add-to-list 'load-path dir) > (setq guix-load-path dir) > (require 'guix-init nil t)) > > '(safe-local-variable-values >(quote > ((bug-reference-bug-regexp . > "") > (custom-set-faces > > /home/glc/.config/guix/latest’ -> ‘../../src/guix' > /root/.config/guix/latest’ -> ‘/home/glc/src/GUI’ > > > Guix would be less stateful (AKA more "stateless") if instead I could > put something like ... > > (guix > (#:use-git #t) > (#:git-directory:"~/src/guix")) It seems to me that it’s not a question of “statefulness”, but rather a question of how much configuration is needed to have guix.el use the Guix that you want. Ludo’.
bug#22994: FAIL: tests/gexp.scm
Jean Louis skribis: > I have run this: > > guix package -i guix > > and it failed: > > FAIL: tests/gexp.scm What does ‘guix build guix -n’ display? TIA, Ludo’.
