Re: About GSoC 2014
Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: Are you applying for other projects as well for this year? I'm also interested in the emacs-xwidget project, but my to be honest, my C level isn't high. I'm not sure if I'm competent at that job. Please familiarize yourself with the tools, and report any issues or questions you may have. It would be great also to start discussing more precisely what the UI should look like, and sketch a road map. OK, I will. -- http://www.gnu.org/software/emacs/
Re: New Hydra build slaves
On 03/03/2014 11:31 PM, Ludovic Courtès wrote: BTW, it would be great if someone would volunteer to help with administration of Hydra and the build machines. So if someone is interested, please let me know. Since I am here at TUM, I can help with volunteering the server here. How can I help? Sree
Re: hydra.gnu.org migrates to /gnu/store!
On 02/28/2014 11:28 PM, Ludovic Courtès wrote: Among other things, it’s migrating from /nix/store to /gnu/store. Is this already present in the master branch? If so, will the store be rebuilt when I update master? Sree
Re: New Hydra build slaves
(Stripping Cc.) Sree Harsha Totakura sreehar...@totakura.in skribis: On 03/03/2014 11:31 PM, Ludovic Courtès wrote: BTW, it would be great if someone would volunteer to help with administration of Hydra and the build machines. So if someone is interested, please let me know. Since I am here at TUM, I can help with volunteering the server here. How can I help? For the machine at TUM, the main issue currently is to get the networking issue that Christian identified sorted out. I was actually thinking of general Hydra administration. Occasionally machines may have troubles, like transient errors (networking, disk space, random build issues, etc.) requiring manual intervention, or occasional Hydra upgrades. There’s also the problem that our current setup is fairly hackish. Having scripts to automate some of the tasks would be an improvement. Thanks, Ludo’.
master: the tests take ages
On master, ‘make check’ hangs after PASS: tests/base32.scm PASS: tests/hash.scm PASS: tests/pk-crypto.scm PASS: tests/pki.scm Any clues? pgpIlOqNfFHML.pgp Description: PGP signature
Re: New Hydra build slaves
On 03/04/2014 12:12 PM, Ludovic Courtès wrote: For the machine at TUM, the main issue currently is to get the networking issue that Christian identified sorted out. AFAIK, Christian has written to the network operations dept. here. I will check with them later. I was actually thinking of general Hydra administration. Occasionally machines may have troubles, like transient errors (networking, disk space, random build issues, etc.) requiring manual intervention, or occasional Hydra upgrades. OK, I can do these. There’s also the problem that our current setup is fairly hackish. Having scripts to automate some of the tasks would be an improvement. We can try setting up some kinda monitoring on the buildslaves which can then send emails when problems arise. WDYT? Sree
Re: New Hydra build slaves
Hi, Ludovic Courtès writes: Sree Harsha Totakura sreehar...@totakura.in skribis: On 03/03/2014 11:31 PM, Ludovic Courtès wrote: BTW, it would be great if someone would volunteer to help with administration of Hydra and the build machines. So if someone is interested, please let me know. Since I am here at TUM, I can help with volunteering the server here. How can I help? […] I was actually thinking of general Hydra administration. Occasionally machines may have troubles, like transient errors (networking, disk space, random build issues, etc.) requiring manual intervention, or occasional Hydra upgrades. There’s also the problem that our current setup is fairly hackish. Having scripts to automate some of the tasks would be an improvement. I'd be pretty interested in getting involved in the system admin. I have experience with scripting and general maintenance of debian based systems, but no specific experience of working with or administrating hydra. Willing to learn though. Let me know what you think — would understand if you're looking for someone with more specific experience. Best wishes, Alex
Re: hydra.gnu.org migrates to /gnu/store!
Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: Among other things, it’s migrating from /nix/store to /gnu/store. Stay tuned! :-) Can you give some advice on how best to transition from /nix/store to /gnu/store on an existing Guix system? Can $PREFIX/var/nix and the sqlite database be shared, or do I have to start with a clean slate? Any other suggestions? Thanks, Mark
Re: New Hydra build slaves
Sree Harsha Totakura sreehar...@totakura.in skribis: On 03/04/2014 12:12 PM, Ludovic Courtès wrote: [...] I was actually thinking of general Hydra administration. Occasionally machines may have troubles, like transient errors (networking, disk space, random build issues, etc.) requiring manual intervention, or occasional Hydra upgrades. OK, I can do these. Excellent! We can discuss the details off-line, possibly with Andreas and Nikita, who have already suffe^W had the opportunity to help. :-) There’s also the problem that our current setup is fairly hackish. Having scripts to automate some of the tasks would be an improvement. We can try setting up some kinda monitoring on the buildslaves which can then send emails when problems arise. WDYT? Yes, that would be great. Also, I hope these can be the first machines to run the full GNU. For that, we’ll need service definitions for a few more things, notably Hydra, for the front-end. Thanks, Ludo’.
Re: New Hydra build slaves
Alex Sassmannshausen alex.sassmannshau...@gmail.com skribis: Ludovic Courtès writes: Sree Harsha Totakura sreehar...@totakura.in skribis: On 03/03/2014 11:31 PM, Ludovic Courtès wrote: BTW, it would be great if someone would volunteer to help with administration of Hydra and the build machines. So if someone is interested, please let me know. Since I am here at TUM, I can help with volunteering the server here. How can I help? […] I was actually thinking of general Hydra administration. Occasionally machines may have troubles, like transient errors (networking, disk space, random build issues, etc.) requiring manual intervention, or occasional Hydra upgrades. There’s also the problem that our current setup is fairly hackish. Having scripts to automate some of the tasks would be an improvement. I'd be pretty interested in getting involved in the system admin. I have experience with scripting and general maintenance of debian based systems, but no specific experience of working with or administrating hydra. Willing to learn though. Great, sounds like a plan! That’s definitely enough knowledge to get started. I will share the basic info about Hydra. We should discuss the details off-line and probably set up a (private?) mailing list to coordinate efforts. Thank you, Ludo’.
Transition to /gnu/store
Mark H Weaver m...@netris.org skribis: Can you give some advice on how best to transition from /nix/store to /gnu/store on an existing Guix system? Can $PREFIX/var/nix and the sqlite database be shared, or do I have to start with a clean slate? Any other suggestions? Sorry, I was planning to mention that eventually. (I have not yet changed the default store directory that ./configure chooses, but will do so in the near future.) You don’t have to migrate to /gnu/store now. You can keep using /nix/store on your machine. The only possible downside is that hydra.gnu.org will no longer provide binaries for /nix/store, so everything will have to be built locally. Also, if you re-configure Guix, you’ll have to make sure to pass --with-store-dir=/nix/store when the default has changed to /gnu/store. Since moving to /gnu/store involves a full re-build or re-download, I recommend doing that once we’ve merged core-updates (hopefully within a couple of weeks.) I would also like to change the database directory to $PREFIX/var/guix. This change is more intrusive: if you want to keep using the store database that’s under $PREFIX/var/nix, you’ll have to manually change the value in Makefile.am. HTH, Ludo’.
Re: core-updates: FAIL: tests/builders.scm; tests/packages.scm; tests/store.scm
Could you send test-suite.log and tests/{builders,packages,store}.log?
(Note: tests/foo.log is different from foo.log!)
Thanks,
Ludo’.
Re: master: the tests take ages
Mark H Weaver m...@netris.org skribis: Nikita Karetnikov nik...@karetnikov.org writes: On master, ‘make check’ hangs after PASS: tests/base32.scm PASS: tests/hash.scm PASS: tests/pk-crypto.scm PASS: tests/pki.scm After tests/pki.scm comes tests/builders.scm, which involves building a few packages from source code. It takes a while. Yes, some of the tests involve downloading a couple of packages, and building them. This takes a while the first time you run ‘make check’, but is fast in subsequent runs (unless you removed ‘test-tmp’.) Thanks, Ludo’.
Re: Signed archives (preliminary patch)
(Could you keep more context when replying, to make it easier to find out what we’re referring to?) Nikita Karetnikov nik...@karetnikov.org skribis: For simplicity, change this pattern to (1 id body). That will allow the inner ‘cond’ to be simplified. I like informative error messages, may I keep it please? The attached diff should address all the things you mentioned except this one. Please review. OK. I’m planning to send a proper patch as soon as I test (guix base64) and change a couple of things in (test-substitute-binary). Cool, thanks! -(define (narinfo-maker cache-url) - Return a narinfo constructor for narinfos originating from CACHE-URL. + (system narinfo-system) + (signaturenarinfo-signature) Add “canonical sexp” as a comment on the right. + ;; The original contents of a narinfo file. This field is needed because we + ;; want to preserve the initial order of fields for verification purposes. + ;; See https://lists.gnu.org/archive/html/guix-devel/2014-02/msg00340.html + ;; for more information. + (contents narinfo-contents)) s/initial order of fields/exact textual representation/ +(define (parse-signature str) + Parse the Signature field of a narinfo file. Rather something like: Return the as a canonical sexp the signature read from STR, the value of a narinfo’s ‘Signature’ field. +(define* (verify-signature sig #:optional (acl (current-acl))) I really prefer something like ‘assert-valid-signature’ (possibly copy/pasted from nar.scm) because: 1. The name reflects that it’s a check whose failure leads to a non-local exit, and that the return value doesn’t matter. 2. ‘assert-valid-signature’ in nar.scm does all the checks, including the hash comparison, which IMO makes it easier to see that we’re not forgetting anything. WDYT? (In the light of Apple’s “goto fail” story, it makes sense to pay extra attention to the way we write these things.) (define (write-narinfo narinfo port) Write NARINFO to PORT. [...] + (set-port-encoding! port UTF-8) + (put-string port (narinfo-contents narinfo))) I’d prefer: (put-bytevector port (string-utf8 (narinfo-contents narinfo))) +(define-module (test-substitute-binary) + #:use-module (guix scripts substitute-binary) + #:use-module (guix base64) + #:use-module (guix hash) + #:use-module (guix pk-crypto) + #:use-module (guix pki) + #:use-module (rnrs bytevectors) + #:use-module ((srfi srfi-64) #:hide (test-error))) + +;; XXX: Replace with 'test-error' from SRFI-64 as soon as it allows to catch +;; specific exceptions. “allows us” +(define %wrong-public-key + ;; (display + ;; (canonical-sexp-string + ;; (find-sexp-token (generate-key (genkey (rsa (nbits 4:1024 + ;;'public-key))) You can remove the comment here. +(test-begin parse-signature) Actually there should be only one ‘test-begin’ per file, and it should be (test-begin file-name-without-extension). That’s because that is then used as the base of the .log file name. +(test-assert valid + (lambda () +(parse-signature %signature))) This test will always pass because (lambda () ...) is true. Instead it should read: (test-assert valid (canonical-sexp? (parse-signature %signature))) For consistency, I would write test-error* like: (define-syntax-rule (test-error* name exp) (test-assert name (catch 'quit (lambda () exp #f) (lambda args #t because then “(lambda () ...)” can be omitted. +(test-error* invalid hash + (lambda () +(read-narinfo (open-input-string (narinfo %signature)) + https://example.com; %acl))) For these tests, could you add one-line comments specifying why they should fail? I’m asking because I got lost as to why %SIGNATURE here should have a hash mismatch. +(test-assert valid + (lambda () +(read-narinfo (open-input-string %signed-narinfo) + https://example.com; %acl))) Same as above: remove (lambda () ...). +(let ((port (open-output-string))) + (test-equal valid +%signed-narinfo +(begin (write-narinfo (read-narinfo (open-input-string %signed-narinfo) +https://example.com; %acl) + port) + (get-output-string port Rather: (test-equal valid %signed-narinfo (call-with-output-string (lambda (port) ...))) Thank you for the great work! Ludo’.
Re: Problems with upgrade to GnuTLS 3.2.12 (important)
Mark H Weaver m...@netris.org skribis: Due to a grave certificate verification flaw, it is quite important that we upgrade to GnuTLS 3.2.12 ASAP, but two of the tests in guile/tests are failing: FAIL: x509-auth.scm FAIL: openpgp-auth.scm For both of the failing tests, the error is the same: /nix/store/lvfp4x9fwsrv158yzag6qf54q262mgzz-guile-2.0.9/bin/guile: symbol lookup error: /tmp/nix-build-gnutls-3.2.12.drv-0/gnutls-3.2.12/guile/src/.libs/guile-gnutls-v-2.so.0: undefined symbol: gnutls_rsa_params_init This is because: 1. the --disable-rsa-export configure option disappeared (it’s been reinstated in GnuTLS commit a1c626e), and so ENABLE_RSA_EXPORT was left undefined, meaning gnutls_rsa_export.c code was not compiled (it’s actually a backward-compatibility interface.) 2. the Guile bindings still use and expose that interface (I’ll ask for advice on what to do here.) I’ll push the upgrade shortly; thanks! Ludo’.
