Re: opendir* missing
I cannot reproduce this on my GuixSD machine; I see the error only on my workstation with Guix on top of Fedora. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: ld-wrapper and funny bytes in LIBRARY_PATH
Hi Ludo, On Sun, 18 Jun 2017 00:21:28 +0200 l...@gnu.org (Ludovic Courtès) wrote: > Danny Milosavljevic skribis: > > > so I'm trying to enable Rust tests and one of their tests does the > > following (paraphrased) in order to exercise the non-UTF8 linker case > > (which they want to succeed): > > > > -- > > bad_dir := zzz$$'\xff' > > > > all: > > mkdir $(bad_dir) > > cp ... $(bad_dir)/liblibrary.a > > LIBRARY_PATH=$(bad_dir) rustc exec.rs > > -- > > > > This fails for us. > > So they expect ‘ld’ to properly deal with UTF-8 file names, right? I think they want ld to properly deal with random file names. 0xFF is not even valid UTF-8. See also: - https://github.com/rust-lang/rust/issues/29122 (initial bug report) - https://github.com/rust-lang/rust/pull/29134 (pull request) - https://github.com/wthrowe/rust/commit/19664fdf8d1b8fc5fd3b359c2440625b2b4d8cec (test) > This is another instance of the file name decoding problem with Guile. > As you know, Guile 2.0/2.2 decodes file names according to the current > locale, and ‘ld-wrapper’ runs Guile. Sigh... Well, I've posted a patch to guix-patches that disables the Rust test in question. Can't do much else than that. The other 15444 Rust tests work now :)
Re: Performance on NFS
Ludovic Courtès writes: […] > So the problem is probably not NFS in this case but rather RPC > performance. > > However, I can’t help with this until you drop ‘guixr’ and use > GUIX_DAEMON_SOCKET=guix:// instead. Hint hint. ;-) FWIW: I’m using GUIX_DAEMON_SOCKET=guix:// since a few days. It allows for a simpler “guixr”, which now only prints extra info and refuses to run on the login node. It’s really nice! I haven’t noticed any difference in performance, but I certainly could test patches. Performance differs a lot for different packages. “guix build bwa” (~ 7 seconds) is a lot faster than “guix build python2-numpy” (> 40 seconds), for example. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: [PATCH] Prototype register-path
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I figured out why I was getting those two test failures after looking more closely at tests/store.log: when I installed GuixSD, I did so directly from another hard drive on the same system (having read in the past about issues with multi-booting, I figured I'd just decide which to boot to by selecting hard drives). I had previously cloned guix on the Ubuntu hard drive, and figured I'd just mount it and copy it over. It turns out that re-running make didn't alter the tests quite as much as I thought it would, and the old path was stuck in some of them (on GuixSD there is no code-downloads folder, it's just straight in Programming/). After a git clean, though, the tests all pass. > Though something went from with your email client. :-) Aye, turns out M-x epa-mail-sign doesn't work well with attachments. I posted another message that should be signed correctly, as well as this one. > What are your thoughts on the next steps? Well, I took a look at libstore/build.cc, and that is a lot of code. I hope I can get away with only reading as much as is necessary to clarify details. To that end, I'd like to make sure that my high-level understanding of the build process is accurate. - - A derivation is a node in a (acyclic?) graph of "what depends on what" or, alternately put, what is input to what. - - Derivations can depend on other derivations or plain files (can those files be directories?), where "plain files" cannot depend on anything else. - - "Building" a derivation involves first ensuring that all of its inputs are "built" (in the case of inputs that are derivations, this means ensuring its output exists as a store item, and if not, producing it by this same process. In the case of plain file inputs, this means just ensuring that they exist as a store item), and then preparing a build environment. The "builder" script is then executed in a chroot rooted under the build tree. After it has completed, the output (where is it put during the build process?) from building the derivation is placed in the store (and registered). - - "preparing a build environment" involves first creating a directory in which the build will be run, then populating it with certain expected files and directories (as detailed in 2.4.1 of the manual). Also, the store items produced from building the inputs need to somehow be made available (is there a gnu/store/ under the build tree? I feel like I don't quite understand where everything goes in the build tree). Also, set any environment variables associated with the derivation. Assuming I've got the gist of it sort of right, that leaves one more question: how are hashes for the paths computed? It's not sha256 like the database hashes, it seems to be 160 bits in size. How are all the inputs hashed together? Are all the inputs put in one big directory and that is hashed in nar form, or what? And what about store items that don't have any inputs (for example, something placed in there with add-text-to-store)? I suppose in that case they are their own input, perhaps? Some of those answers might be in the manual, but I didn't manage to find them. -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEdNapMPRLm4SepVYGwWaqSV9/GJwFAllGRk0ACgkQwWaqSV9/ GJw9TQf/W8ewHEFzwTssGhMGW/pGsSvUMnzdQNmx31Y1HLMpUbhBazbIUa57pz5g ZfDbUIRnKBYlCPi5X+8Om8fzMjWpUixYeyv/Clk3sRvbcQhod0cejbRIC0PAiTN0 mVlu4tUWJlEXekcG7OqhdZ8AZXJ53qOkNMEHR3h91PCJOZj2fOVwzlC5kp7gUfcM C9a/rgCb6ZG6dXQNH3Q0qI38+akDg3tbD0BDk97yhHCBSVitwbJd9vTiEl3QhAPP WFlZjmZGFpfruZiuRDyO8pOFC4tfdsEy/wv4spjq63ZgBNqLQsI9Y0JfXJWM/fEH d+KsI54ix/yDhZnbZofLaogAH3Fo8w== =Ukhf -END PGP SIGNATURE-
Re: Upgrading packages with substitutes only (bug #26608)
Ludovic Courtès writes: > BTW, should --only-substitutes filter out packages without a substitute, > or should it simply stop and report the list of missing substitutes > (after which the user could use --do-not-upgrade)? In my opinion “--only-substitutes” should stop and report a list. If it continued without complaining there could be problems: * partial upgrades could leave the profile in an unusable state * an attacker could use this to trick a user into thinking that they have all available updates On the other hand, it would make “--only-substitutes” less usable, because to actually perform work one would have to deal with the failure case. I suppose it could download the substitutes but not build a new profile and report an error at that point. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
‘core-updates’ building!
Hello Guix! I went ahead and started an evaluation of the full package set for ‘core-updates’: https://hydra.gnu.org/jobset/gnu/core-updates I think we should focus on fixing remaining build issues now. Thanks, Ludo’.
Re: ld-wrapper and funny bytes in LIBRARY_PATH
Hi Danny, Danny Milosavljevic skribis: > On Sun, 18 Jun 2017 00:21:28 +0200 > l...@gnu.org (Ludovic Courtès) wrote: > >> Danny Milosavljevic skribis: >> >> > so I'm trying to enable Rust tests and one of their tests does the >> > following (paraphrased) in order to exercise the non-UTF8 linker case >> > (which they want to succeed): >> > >> > -- >> > bad_dir := zzz$$'\xff' >> > >> > all: >> > mkdir $(bad_dir) >> >cp ... $(bad_dir)/liblibrary.a >> >LIBRARY_PATH=$(bad_dir) rustc exec.rs >> > -- >> > >> > This fails for us. >> >> So they expect ‘ld’ to properly deal with UTF-8 file names, right? > > I think they want ld to properly deal with random file names. 0xFF is not > even valid UTF-8. > > See also: > - https://github.com/rust-lang/rust/issues/29122 (initial bug report) > - https://github.com/rust-lang/rust/pull/29134 (pull request) > - > https://github.com/wthrowe/rust/commit/19664fdf8d1b8fc5fd3b359c2440625b2b4d8cec > (test) OK. >> This is another instance of the file name decoding problem with Guile. >> As you know, Guile 2.0/2.2 decodes file names according to the current >> locale, and ‘ld-wrapper’ runs Guile. > > Sigh... Yeah. :-/ > Well, I've posted a patch to guix-patches that disables the Rust test in > question. Can't do much else than that. > > The other 15444 Rust tests work now :) Awesome, thank you! Ludo’. PS: Your email address has been bouncing lately.
Differences between container used by "guix build" and "guix environment -C -N"
Hi, I'm trying to track down the test_process_mask problem in Guix when trying to test rustc. For that I did: (apply attached patch) $ guix build --keep-failed rustc # will fail $ cd /tmp/guix-build-rustc-1.16.0.drv-0 $ guix environment -C -N rustc $ bash $ source environment-variables $ cd rustc-1.16.0-src $ ./x86_64-unknown-linux-gnu/stage2/test/stdtest-x86_64-unknown-linux-gnu 2>&1 |grep test_process_mask will not fail. Why does it fail in "guix build", then? Q Description: Binary data
Re: ‘core-updates’ building!
On Sun, Jun 18, 2017 at 11:49:06AM +0200, Ludovic Courtès wrote: > Hello Guix! > > I went ahead and started an evaluation of the full package set for > ‘core-updates’: > > https://hydra.gnu.org/jobset/gnu/core-updates > > I think we should focus on fixing remaining build issues now. Okay! I won't be able to help as much as usual in the next week. Hopefully afterwards, I'll have more time. Good luck! signature.asc Description: PGP signature
Re: Upgrading packages with substitutes only (bug #26608)
On Sun, Jun 18, 2017 at 11:38:45AM +0200, Ricardo Wurmus wrote: > > Ludovic Courtès writes: > > > BTW, should --only-substitutes filter out packages without a substitute, > > or should it simply stop and report the list of missing substitutes > > (after which the user could use --do-not-upgrade)? I like making it return a list on stdout so it can be composed as suggested. > In my opinion “--only-substitutes” should stop and report a list. > If it continued without complaining there could be problems: > > * partial upgrades could leave the profile in an unusable state > > * an attacker could use this to trick a user into thinking that they > have all available updates > > On the other hand, it would make “--only-substitutes” less usable, > because to actually perform work one would have to deal with the failure > case. > > I suppose it could download the substitutes but not build a new profile > and report an error at that point. Perhaps there could be an additional flag --partial-upgrade to make it build a new profile. I understand why people want --only-substitutes but I'm a bit wary of it for the reasons you gave, and I think we should solve their complaint by improving our build infrastructure. signature.asc Description: PGP signature
fails make on core-updates
Hello, On core-updates branch, after running: git pull ./bootstrap ./configure --localstatedir=/var make error appears: CXX nix/libstore/libstore_a-sqlite.o AR libstore.a ar: `u' modifier ignored since `D' is the default (see `U') CXX nix/nix-daemon/guix_daemon-nix-daemon.o CXX nix/nix-daemon/guix_daemon-guix-daemon.o CXXLDguix-daemon nix/nix-daemon/guix_daemon-nix-daemon.o: In function `nix::FormatOrString::FormatOrString(boost::basic_format const&)': /home/jin/gits/guix/./nix/libutil/types.hh:36: undefined reference to `boost::basic_format::str[abi:cxx11]() const' nix/nix-daemon/guix_daemon-nix-daemon.o: In function `daemonLoop()': /home/jin/gits/guix/nix/nix-daemon/nix-daemon.cc:950: undefined reference to `boost::basic_format::basic_format(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&)' nix/nix-daemon/guix_daemon-nix-daemon.o: In function `nix::FormatOrString::FormatOrString(boost::basic_format const&)': /home/jin/gits/guix/./nix/libutil/types.hh:36: undefined reference to `boost::basic_format::str[abi:cxx11]() const' /home/jin/gits/guix/./nix/libutil/types.hh:36: undefined reference to `boost::basic_format::str[abi:cxx11]() const' /home/jin/gits/guix/./nix/libutil/types.hh:36: undefined reference to `boost::basic_format::str[abi:cxx11]() const' /home/jin/gits/guix/./nix/libutil/types.hh:36: undefined reference to `boost::basic_format::str[abi:cxx11]() const' /home/jin/gits/guix/./nix/libutil/types.hh:36: undefined reference to `boost::basic_format::str[abi:cxx11]() const' nix/nix-daemon/guix_daemon-nix-daemon.o:/home/jin/gits/guix/./nix/libutil/types.hh:36: more undefined references to `boost::basic_format::str[abi:cxx11]() const' follow collect2: error: ld returned 1 exit status make[2]: *** [Makefile:3162: guix-daemon] Error 1 make[2]: Leaving directory '/home/jin/gits/guix' make[1]: *** [Makefile:4308: all-recursive] Error 1 make[1]: Leaving directory '/home/jin/gits/guix' make: *** [Makefile:2898: all] Error 2
Re: Small package re-organization proposal
Leo Famulari writes: > On Fri, Jun 16, 2017 at 10:29:09AM +0200, Ricardo Wurmus wrote: >> >> Kei Kebreau writes: >> >> > I think it may be a good idea to consolidate spelling and grammar >> > packages into language.scm (or a new spelling.scm file if the former is >> > not appropriate). This would include packages such as aspell and its >> > dictionaries, hunspell, enchant, and any others that I might be missing. >> > >> > Any thoughts on this? >> >> I have no preference here. I think we should avoid moving around >> modules between releases, because it needlessly breaks third-party >> repositories (used with GUIX_PACKAGE_PATH). > > Also, I think we should do this kind of reorganization between > core-updates cycles. Otherwise the merges tend to be trickier. Okay. Since this is mostly a cosmetic fix (at least that's what it seems to me), I'm fine with letting it go. It's good to know when these sorts of things are most appropriate within our development cycle. signature.asc Description: PGP signature
Re: Upgrading packages with substitutes only (bug #26608)
Leo Famulari writes: > On Sun, Jun 18, 2017 at 11:38:45AM +0200, Ricardo Wurmus wrote: >> >> Ludovic Courtès writes: >> >> > BTW, should --only-substitutes filter out packages without a substitute, >> > or should it simply stop and report the list of missing substitutes >> > (after which the user could use --do-not-upgrade)? > > I like making it return a list on stdout so it can be composed as > suggested. While the user experience would suffer a bit, it’s no real hardship to type $ guix package \ --do-not-upgrade $(guix package --only-substitutes -u) \ -u This is definitely possible. >> In my opinion “--only-substitutes” should stop and report a list. >> If it continued without complaining there could be problems: >> >> * partial upgrades could leave the profile in an unusable state Maybe I don’t understand Guix that well yet, but I don’t think this is possible. At least I don’t understand how it would happen. Under the hood, the “--only-substitutes” flag would basically just be an intelligent “--do-not-upgrade” flag. Can I ruin my profile by misusing “--do-not-upgrade”? >> * an attacker could use this to trick a user into thinking that they >> have all available updates I can always run $ guix package -n -u to learn what packages are out of date. (Except if I get frustrated by the fact that Guix is building a package to check if is different from an installed package and mash C-c C-c. :)) Also, my original implementation added a “the following packages will be excluded” line, that let the user know which packages are being omitted from the upgrade. This will be harder to do with Ludo’s suggestion, though. >> On the other hand, it would make “--only-substitutes” less usable, >> because to actually perform work one would have to deal with the failure >> case. >> >> I suppose it could download the substitutes but not build a new profile >> and report an error at that point. > > Perhaps there could be an additional flag --partial-upgrade to make it > build a new profile. > > I understand why people want --only-substitutes but I'm a bit wary of it > for the reasons you gave, and I think we should solve their complaint by > improving our build infrastructure. I agree wholeheartedly with improving the build infrastructure! I’m just less certain about how I could help with that…. In the short term, this is my way of working around the infrastructure issues. -- Tim
Re: New git signing key for Eric Bavier?
On Sun, 18 Jun 2017 01:30:07 -0400 Mark H Weaver wrote: > Hi Eric, > > bav...@member.fsf.org (Eric Bavier) writes: > > bavier pushed a commit to branch master > > in repository guix. > > > > commit d56c55fffbe962cf7c44030ae4eac53ffa1e1f85 > > Author: Eric Bavier > > Date: Thu Jun 15 00:37:17 2017 -0500 > > > > gnu: tomb: Upgrade to 2.4. > > This commit, and another recent commit (e0c9530) of yours, were signed > using a key that's different from the one you've previously used to sign > commits, and different from the key you have registered on Savannah. > > Can you please confirm that A0C5E3522EF8EF5C64CDB7F0FD73CAC719D32566 is > your new key, That is indeed my new key. > sign it with your old key if possible, and upload this new > key to Savannah? I've just put the new key on Savannah. It should be signed with my old key. Thanks for saying something. I'm still learning things about gpg. `~Eric pgpYYURcrJOCT.pgp Description: OpenPGP digital signature
Re: New git signing key for Jan Nieuwenhuizen?
Jan Nieuwenhuizen writes: > Mark H Weaver writes: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > >>> commit ebfb71d45615698040818a68b7dc34996ff4c046 >>> gpg: Signature made Fri 16 Jun 2017 07:22:49 AM EDT >>> gpg:using RSA key DB34CB51D25C9408156FCDD6A12F87978D701B99 >>> gpg: Can't check signature: No public key >>> Author: Jan Nieuwenhuizen >>> Date: Thu Jun 15 19:22:00 2017 +0200 >>> >>> tests: Allow setting of qemu memory-size for system tests. >>> >>> * gnu/system/vm.scm (common-qemu-options): Remove hardcoded "-m 256". >>> (system-qemu-image/shared-store-script): New keyword argument: >>> #:memory-size. >> >> This commit was signed using a different key than the one you've been >> using for your other commits, and different from the one you have >> registered on Savannah. >> >> Is DB34CB51D25C9408156FCDD6A12F87978D701B99 your key? > > Yes, that's my new key. Oops. I have updated my key on savannah. > janneke > -BEGIN PGP SIGNATURE- > > iQIzBAEBCAAdFiEE2zTLUdJclAgVb83WoS+Hl41wG5kFAllGFv4ACgkQoS+Hl41w > G5mcHg/+Pd3AvBLSmoPUrXrhFcFrhQyVdq/d6f2R0JiSkrPy402P003Bp6pzEdD8 > OxQzT/ahk7XYRrD0KywCzn6Vd3b7xd+pnBzAJ3TV7lzyXKg97qm6CAAMEdaLNd/3 > 18dKOUmGI5oTRAvTc7Ubdwc4E1qmI4ckBT3QW2LBDOzPaMY6wiLgIA8vETN2bq+S > vIMN9XDQRbtdwwA+k2fXQUB8b5N+bWdc1/YH5DmuqhKUiaHVCHHBc2K5L8YEydPr > 0o+MrbwpmlxXjmKQTYFX8L5Wc1DARWECbPIa70TB53uWIxSQdfQQha/Oqd1fMYU0 > H9jPBF0PJHjJMyrTwmvMrZFC9Xi4u3UnKdCOPOCz2DXTttOGsGRsP16so34e9UzR > DyLD7kR9K/m5djxSYLcIr8mMAfPJ0g/mk1Jyj5Yv9MZVCmFggcfeamirgcvnClxe > Nhkfyf7SPeq/qpKIVpIOabthtuuoYiH2imnlLCL+TS6qGZYtBkhxlKUjRYMFWm+F > bTwo3c+FdwOeyWdKn4a6QwIzfaJ70o1EeIYS4MUCyB1TKzcsJWE/t5R0SOqz1SX5 > ofLsn8amwE0dnoCKQhX92sse+sq4ITj3oD5YpehBl4pvzeIs+7LpLHJSVDSFRfwT > N1Xy/PscHohFgcbfD8dZn/xtxRTN8dz1ysrhwLRBl8zc/tRKYPA= > =xmQy > -END PGP SIGNATURE- Though I didn't confirm in-person, Janneke and I have had other interactions using this key to make me reasonably confident it's their key. signature.asc Description: PGP signature
Re: Upgrading packages with substitutes only (bug #26608)
Timothy Sample writes: >>> In my opinion “--only-substitutes” should stop and report a list. >>> If it continued without complaining there could be problems: >>> >>> * partial upgrades could leave the profile in an unusable state > > Maybe I don’t understand Guix that well yet, but I don’t think this is > possible. At least I don’t understand how it would happen. Under the > hood, the “--only-substitutes” flag would basically just be an > intelligent “--do-not-upgrade” flag. Can I ruin my profile by misusing > “--do-not-upgrade”? There are many cases where partial profile upgrades are okay, especially if software is independent. Problems usually arise when you have things like Python modules in your profile. Upgrading some Python modules but not others might lead to problems at runtime. Arguably, one should be using manifests anyway when consistency is required. >>> * an attacker could use this to trick a user into thinking that they >>> have all available updates > > I can always run > > $ guix package -n -u > > to learn what packages are out of date. (Except if I get frustrated by > the fact that Guix is building a package to check if is different from > an installed package and mash C-c C-c. :)) ^^^ Oh, another “M-x shell” user :) -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: [OFF-TOPIC] Anyone providing gratis mailing list hosting for any small group?
Hello. I am the person Adonay is aiding. On 14 June 2017 at 09:50, Adonay Felipe Nogueira wrote: > NOTE: I'm Cc'ing the person I'm aiding, but I don't know if the person is > subscribed to the list, so I think you should send a wide reply I have just subscribed to guix-devel. > However, I'm not the one directly interested in the service, instead, > I'm aiding the person on contacting you because I don't know if he > speaks/writes in English yet I speak English; in fact, I am better at English than at Spanish. > As part of my attempt to aid the person, I ask if there is someone > here hosting a mailing list service, preferably gratis, for a small > group of people and temporary use? It can also be paid, as long as it is inexpensive. > If I read correctly, the mailing list is for a religious class/course. One list would be for school classes; another would be for a Catholic prayer group (which currently chats online via a WhatsApp group). And today I realized I need a third list, for discussing management of the family's farm; currently we use a Telegram group for that. -- - I am Brazilian. I hope my English is correct and I welcome feedback - Please adopt free formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z - Free (as in free speech) software for Android: https://f-droid.org/
Re: zipbomb handling should not be done in url-fetch/zipbomb
On June 17, 2017 3:13:33 PM CDT, l...@gnu.org wrote: >Arun Isaac skribis: > >> * Proposal >> >> zip bomb (zip archives without a top level directory) handling should >> not be done in `url-fetch/zipbomb'. It should be implemented as a >> boolean argument to the `unpack' phase. > >I guess the Boolean argument would determine whether to do (chdir >(first-subdirectory ".")), right? > >Unfortunately that’s not enough for the cases where an origin has >patches or a snippet, because that code also assumes there’s only one >subdirectory (see ‘patch-and-repack’ in (guix packages)). > >Perhaps the right fix would be to fix ‘patch-and-repack’ somehow. I think this would be preferable. Since it means that users of 'guix build -S' would still get "unbombed" sources. `~Eric -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [PATCH] Prototype register-path
Hi Caleb, I'm sure Ludo may have more to say, but I think I can help you with a few of your questions. Caleb Ristvedt writes: >> Though something went from with your email client. :-) > > Aye, turns out M-x epa-mail-sign doesn't work well with attachments. I > posted another message that should be signed correctly, as well as this > one. Looks like your latest email was signed correctly. I see that it was signed using your Savannah key, which has the following fingerprint: 74D6 A930 F44B 9B84 9EA5 5606 C166 AA49 5F7F 189C > - A derivation is a node in a (acyclic?) graph of "what depends on what" or, > alternately put, what is input to what. I don't think there's a simple answer for the question of "what is a derivation"? I'll explain what I know, and hopefully it'll help you. No, derivations cannot depend on one another [1]. I believe it is correct to think of a derivation as a node in an acyclic graph of inter-dependent software components; that is one way to think about derivations. Perhaps Ludo can say more about that. The word "derivation" is a bit overloaded. Fundamentally (and vaguely), it means "a component build action, which *derives* the component from its inputs" [2]. More specifically, there are various interpretations of the word "derivation", depending on the context. For example, there are structs in the Nix C++ source code that represent derivations [3]. In the Nix expression language, derivations are represented as attribute sets [4]. There are also "store derivations", which are files in the store that precisely encode the build actions that will be executed when the derivation is built [5]. Some of this carries over to Guix. The general meaning of the word "derivation" appears to be the same as in Nix: a derivation basically takes inputs and produces an output. Guix also uses "store derivations" because we use (a modified version of) the Nix daemon. Note that the Guix manual sometimes uses the word "derivation" to refer to "store derivations", which can be confusing. As you probably know, Guix eschews the Nix expression language in favor of Guile for composing components. Therefore, Guix has defined abstractions in Guile to represent derivations [6]. Guix has also defined additional abstractions to represent things like packages [7], which are higher level abstractions than derivations. There are a lot of abstractions like this in Guix, and they interact with each other in various ways. To get an idea of what I mean, you can look at the '(guix) Invoking guix graph' section in the Guix manual. Derivations are a general concept taken from Nix, but as far as I know, things like bags and packages are Guix-specific concepts. > - "Building" a derivation involves first ensuring that all of its inputs are > "built" (in the case of inputs that are derivations, this means ensuring its > output exists as a store item, and if not, producing it by this same > process. In the case of plain file inputs, this means just ensuring that > they > exist as a store item), and then preparing a build environment. The > "builder" > script is then executed in a chroot rooted under the build tree. After it > has > completed, the output (where is it put during the build process?) from > building the derivation is placed in the store (and registered). Note that sometimes the word "build" is used to refer to the act of creating a derivation, but not executing its build actions [8]. The process you've described sounds basically right to me; Ludo probably knows more. The Nix thesis might be out of date by now, but it describes (described?) these kinds of things in pretty good detail [9]. It also describes the invariants that must be upheld by the entire process. > - "preparing a build environment" involves first creating a directory >in which > the build will be run, then populating it with certain expected files and > directories (as detailed in 2.4.1 of the manual). Also, the store items > produced from building the inputs need to somehow be made available (is > there > a gnu/store/ under the build tree? I feel like I don't quite understand > where > everything goes in the build tree). Also, set any environment variables > associated with the derivation. I believe that inputs and outputs are, from the a derivation's builder's perspective, just paths in the store which can be accessed via environment variables that Nix sets up during the build. I think this is the same in Guix as in Nix. However, in Guix, I believe there are additional ways to refer to inputs when defining a builder, e.g. by using G-Expressions, which hide details like this from the user so that the user can reason about builds in terms of higher-level abstractions. As for how the store items produced from building the inputs are "made available," my understanding is that the builder just needs to write files to the special "output" path, which (I think) is in the store. That spec
Re: Upgrading packages with substitutes only (bug #26608)
On Sun, Jun 18 2017, Timothy Sample wrote: > While the user experience would suffer a bit, it’s no real hardship to > type > > $ guix package \ > --do-not-upgrade $(guix package --only-substitutes -u) \ > -u > > This is definitely possible. Just checking: is the proposal that --only-substitutes /always/ prints a list of packages without substitutes? My understanding was that it would only print the list if there were packages without substitutes (thus making the above potentially incorrect/wasteful if everything has a substitute, because you shouldn't unconditionally re-run `guix package`). I don't know if we should conflate "upgrade my profile" with "print a list of packages without substitutes". Those aren't the same requests. I'm more in favour of it continuing and building the new profile, but printing a list of packages which didn't have substitutes. If the user wants to roll-back the upgrade then they can easily do so, but they asked for it to be upgraded and we can still do that. Carlo signature.asc Description: PGP signature
Re: ‘core-updates’ building!
l...@gnu.org (Ludovic Courtès) writes: > I went ahead and started an evaluation of the full package set for > ‘core-updates’: > > https://hydra.gnu.org/jobset/gnu/core-updates > > I think we should focus on fixing remaining build issues now. Almost(?) all of the builds on armhf failed because of an early guile-2.2.2 build timing out after 1 hour of silence. I set the 'max-silent-time' property to 6 hours in the package bound to 'guile-2.2' in (gnu packages guile), but maybe the same property needs to be set elsewhere, e.g. in 'guile-2.2/fixed' and maybe some other places? Mark
Re: ‘core-updates’ building!
Mark H Weaver writes: > l...@gnu.org (Ludovic Courtès) writes: > >> I went ahead and started an evaluation of the full package set for >> ‘core-updates’: >> >> https://hydra.gnu.org/jobset/gnu/core-updates >> >> I think we should focus on fixing remaining build issues now. > > Almost(?) all of the builds on armhf failed because of an early > guile-2.2.2 build timing out after 1 hour of silence. > > I set the 'max-silent-time' property to 6 hours in the package bound to > 'guile-2.2' in (gnu packages guile), but maybe the same property needs > to be set elsewhere, e.g. in 'guile-2.2/fixed' and maybe some other > places? For now, in order to get the ball rolling, I started a manual build (i.e. from the command line) of the timed-out derivation on Hydra, with the --max-silent-time and --timeout options. After that's completed, we can restart the dependency-failed jobs. Mark
