Re: [GSoC] GNUnet binary distribution system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/03/2014 04:35, Mark H Weaver wrote: Pierre-Antoine Rault p...@rigelk.eu writes: On 10/03/2014 22:09, Ludovic Courtès wrote: The initial discussion [0] left open the question of where binaries themselves should be stored. A possibility would be to use GNUnet’s DHT simply as a discovery mechanism, and then to establish a connection directly to the user’s machine, which would run, say, an HTTP server. That's what I had in mind. Now, considered the post [2] by Christian Grothoff, we might consider using either an HTTP server for performance or GNUnet's MESH for anonymity (and security). We should balance needs and ease of implementation. [2] http://lists.gnu.org/archive/html/guix-devel/2014-03/msg00113.html FWIW, I think it might be worthwhile to support BitTorrent magnet links as well, as a middle ground between these two extremes. Most users will not be able to host binaries via HTTP; even if they have a server, the bandwidth requirements are hard to predict and likely to be too high. I'm not sure to understand why you precise BitTorrent magnet links. Magnet is a de-facto standard that is independant from BitTorrent [3] [4], and using BitTorrent in our case wouldn't have better performance than GNUnet's MESH. The only user case when BitTorrent might come in handy is when one wants to download a binary (as one would download a .deb) before manually installing it with guix ; i suppose this can also be done through GNUnet. Then of course it's just a user case: users might be more familiar with BitTorrent. [3] http://magnet-uri.sourceforge.net/ [4] http://magnet-uri.sourceforge.net/magnet-draft-overview.txt I hope this makes sense :) - - rigelk -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTHrRnAAoJEHfJ0QE7gLd6mcMH/A3dlgu2UAJKo3JzR7RSdf8M 2V4xxw4d+vNNPqpIBRYsfJUVkRxePmAljntzsgTQ59AbibAjMt5uXI2htqYAGFia nsXvSIv0YkkPoE15morUtL8XYohRNvkSmaSKR2EqX/+Vxxm7C3Ftni4tlIbLB13k afK/ExDYV2+SoASS5myPqCaK3jusCmCeXlew2aDInbn7owGgtA4dxvti5TtfGaUi IMp/xXb3jimzIyzWbX+rKCvouVRK+ncdBxGzw+kPMtE6h5hja70M0Mw6IaREvJqA dj9mb5YU+OUoLrayVM/PcTML2gqYHhoXkSDQzqsWHLfbtxq0ymUWcnOe2d/WdGY= =JIQ8 -END PGP SIGNATURE-
Re: [patch] - Packaging guideline documentation update
Pierre-Antoine Rault p...@rigelk.eu skribis: On 10/03/2014 21:56, Ludovic Courtès wrote: I’ve applied a stripped-down version of the patch: I ended up removing “Packaging 101” because it was redundant with the “Packaging Guidelines” section of the manual, so I moved the missing bits in that section (info (guix) Packaging Guidelines). I also removed details about how ‘git format-patch’ and co. work, because these commands already have their own manual. I admit it was overkill :) I realize the manual can be improved when it comes to introductory material. I would think of a (not so) short explaination of the guix tree as seen in the GNUnet manuel, for instance. What do you think ? Hmm, perhaps. Actually, part of the module name space is described here in there. For instance (gnu packages ...) is described under “Package Modules”, (guix build ...) is described under “Derivations”, etc. Perhaps a new section with cross-refs to these would help? Ludo’.
Re: master: FAIL: tests/store.scm
Apologies for the sloppy reporting. Let me explain why it’s the case. I ran ‘make check’ multiple times. These tests failed when I cloned the repo and ran ‘make check’ for the first time: tests/derivations.scm, tests/store.scm, tests/guix-build.sh, tests/guix-register.sh. These ones failed when I reran ‘make check’: tests/store.scm, tests/guix-build.sh, tests/guix-register.sh. Then I deleted the tree and cloned again. tests/builders.scm, tests/store.scm, tests/guix-build.sh, tests/guix-register.sh failed. When I ran ‘make check’ once again, the following tests failed: tests/store.scm, tests/guix-build.sh, tests/guix-register.sh. Which log files would you like to see? pgpmWJBCcyXtw.pgp Description: PGP signature
Re: Signed archives (preliminary patch)
I think the current docstring of ‘assert-valid-signature’ is not correct since ‘signature’ must be a string (as produced by ‘canonical-sexp-string’), not an sexp. In guix/nar.scm, the comment is: (define (assert-valid-signature signature hash file) ;; Bail out if SIGNATURE, an sexp, doesn't match HASH, a bytevector ;; containing the expected hash for FILE. and indeed, SIGNATURE must be a string here. Similarly, the “signature is not a valid s-expression” and “corrupt signature data” messages are a bit confusing due to the way ‘string-canonical-sexp’ works (try ‘string-canonical-sexp foo’). But I may be wrong about the latter. Ah right, you could get “corrupt signature data” when (string-canonical-sexp signature) returns the null canonical sexp, whereas you’d want “not a valid s-expression”. Well, we can fix that in a separate patch if you want. Do you have time for this? I think it would be much easier for you than for me because you wrote the bindings. +(define* (assert-valid-signature signature hash port + #:optional (acl (current-acl))) + ;; Bail out if SIGNATURE, a string, doesn't match HASH, a bytevector + ;; containing the expected hash for PORT. Make it a docstring. Also, please make this change a separate patch. OK. + (let* ((file (port-filename port)) I don’t think this will work, because most of the time PORT is a pipe (an input port), whereas FILE is supposed to be the name of the file being restored. What can we do about it? Should the function accept ‘file’ and ‘port’? +(raise (condition (message (message invalid hash)) + (nar-invalid-hash-error + (port port) (file file) + (signature signature) + (expected (hash-data-bytevector data)) + (actual hash) +(raise (condition (message (message unauthorized public key)) + (nar-signature-error + (signature signature) (file file) (port port) +(raise (condition +(message (message corrupt signature data)) +(nar-signature-error + (signature signature) (file file) (port port))) Actually, the problem with making ‘assert-valid-signature’ public is that it raises nar error conditions. It could be changed to raise a more generic signature-error, but then ‘restore-file-set’ would have to guard against it to re-throw it along with a nar-error (making a compound condition.) And then ui.scm would figure it out. Blech. It’s worth factorizing, but I don’t see how to do it nicely. Thoughts? Haven’t thought of it yet. But I’ll try to take care of this one. pgp40XlIJShHd.pgp Description: PGP signature
[GSoC] Porting Guix to GNU/Hurd
Hello Guix , Hello Hurd Most of you already know me from the irc ,lurking around as phant0mas and that I am working towards porting Guix to GNU/Hurd. In order to be able to do that I have already packaged mach headers ,hurd headers and mig and I am currently working on packaging and cross-building hurd's glibc with libpthread as an addon. Here is a simple roadmap explaing what is there to be done. 1) Successfully cross-build the hurd's glibc 2) Make the appropriate changes to cross-base.scm so the toolchain will use the new glibc when hurd is targeted with guix build --target=i686-gnu bootstrap-binaries 3) Successfully cross-build Guix's bootstrap binaries. This will be the first milestone. 4) At this point we can try bootstraping guix in a native Hurd system while starting modifying the (gnu system) Guix modules in order to add support for a GNU/Hurd system. 5) After adding support for a Hurd system and configuring system packages ,services , etc ,we could create a complete VM image of a GNU/Hurd system. When we have that last one ,as it was pointed out from Thomas Schwinge in the irc, we'll be easily able to change some detail in, say, glibc, rebuild the whole system, and see whether it still works. And because I am an eligible student I would like to apply as a GSoC student working on this. I am reading any available documentation or existing source that can help me and I would really appreciate any suggestions ,corrections or questions that can help me. Manolis Ragkousis
Re: master: FAIL: tests/store.scm
Nikita Karetnikov nik...@karetnikov.org skribis: Which log files would you like to see? The SRFI-64 $top_builddir/*.log files, and $top_builddir/test-suite.log. The topological sort issue is normally solved by 58cbbe4. Ludo’.
Re: error: build failed: committing transaction: disk I/O error
Mark H Weaver m...@netris.org skribis: In recent weeks on my system, it has become fairly common for the daemon to get into a bad state, where all build attempts fail with messages like this: mhw:~/guix-core-updates$ ./pre-inst-env guix build -n emacs error (ignored): aborting transaction: cannot rollback - no transaction is active guix build: error: build failed: committing transaction: disk I/O error mhw:~/guix-core-updates$ (The message comes from SQLite.) Restarting 'guix-daemon' always fixes it, until the next time. Note that this happens on the master branch too, not just core-updates. This is on my MIPS system (YeeLoong 8101B with Loongson 2F CPU). I'm not sure if that's relevant. Has anyone else seen this? No, but could it have something to do with the file system or SQLite issues encountered on MIPS? http://lists.gnu.org/archive/html/guix-devel/2013-10/msg00185.html Ludo’.
Re: [GSoC] Porting Guix to GNU/Hurd
Hello! Manolis Ragkousis manolis...@gmail.com skribis: Here is a simple roadmap explaing what is there to be done. 1) Successfully cross-build the hurd's glibc 2) Make the appropriate changes to cross-base.scm so the toolchain will use the new glibc when hurd is targeted with guix build --target=i686-gnu bootstrap-binaries 3) Successfully cross-build Guix's bootstrap binaries. This will be the first milestone. 4) At this point we can try bootstraping guix in a native Hurd system while starting modifying the (gnu system) Guix modules in order to add support for a GNU/Hurd system. 5) After adding support for a Hurd system and configuring system packages ,services , etc ,we could create a complete VM image of a GNU/Hurd system. Sounds like a good plan! I can see really 3 milestones: 1. Getting cross-compilation support to i686-gnu in order with Guix. 2. Getting native compilation on i686-gnu in order. 3. Building a bootable system or VM image. You’re already on your way for item #1. As you noticed, that’s already non-trivial work, for various reasons. And because I am an eligible student I would like to apply as a GSoC student working on this. Good. Make sure to apply in google-melange too. I can mentor the project, but I would really like someone from the Hurd side to co-mentor. Any volunteer? (This is essentially already the case in practice, but we could make it official.) Thanks! Ludo’. PS: Please avoid HTML in messages.
Re: [patch] - Packaging guideline documentation update
Cross-refs and a small glossary would help a lot to start with Guix. However, I was thinking about an explanation of folders, sub folders and main files as seen in the GNUnet manual [1]. [1] https://gnunet.org/book/export/html/37 Of course, these are just ideas to help brainstrom :) - rigelk l...@gnu.org a écrit : Pierre-Antoine Rault p...@rigelk.eu skribis: On 10/03/2014 21:56, Ludovic Courtès wrote: I’ve applied a stripped-down version of the patch: I ended up removing “Packaging 101” because it was redundant with the “Packaging Guidelines” section of the manual, so I moved the missing bits in that section (info (guix) Packaging Guidelines). I also removed details about how ‘git format-patch’ and co. work, because these commands already have their own manual. I admit it was overkill :) I realize the manual can be improved when it comes to introductory material. I would think of a (not so) short explaination of the guix tree as seen in the GNUnet manuel, for instance. What do you think ? Hmm, perhaps. Actually, part of the module name space is described here in there. For instance (gnu packages ...) is described under “Package Modules”, (guix build ...) is described under “Derivations”, etc. Perhaps a new section with cross-refs to these would help? Ludo’.
Re: [GSoC] GNUnet binary distribution system
Pierre-Antoine Rault p...@rigelk.eu skribis: On 10/03/2014 22:09, Ludovic Courtès wrote: [...] The initial discussion [0] left open the question of where binaries themselves should be stored. A possibility would be to use GNUnet’s DHT simply as a discovery mechanism, and then to establish a connection directly to the user’s machine, which would run, say, an HTTP server. That's what I had in mind. Now, considered the post [2] by Christian Grothoff, we might consider using either an HTTP server for performance or GNUnet's MESH for anonymity (and security). We should balance needs and ease of implementation. [2] http://lists.gnu.org/archive/html/guix-devel/2014-03/msg00113.html Yes. Could you experiment with the MESH interface, and sketch how files would be served concretely? You could use the ‘gnunet-mesh’ command-line tool for quick experimentation, although I haven’t found its documentation. [...] * I think we should focus on ease of use, since it could become a good alternative to setting up a full fledged server to share officially supported packages and unofficial ones (like the AUR for Archlinux). That’s been discussed before (see http://lists.gnu.org/archive/html/guix-devel/2013-08/msg00127.html), but it’s orthogonal. Then we have to extend the guix tools to cover user modules (overlays, that is). Yes, but as I said, this is unrelated to the project at hand. This proposal needs discussion with both Guix and GNUnet people (and notably Sree Harsha, who is at the intersection of both projects :-)), to work towards a concrete road map of things to hack on. Sure ; It's the only way to have a clear and shared view of what parts of Guix are involved in the project. I'm working on a roadmap draft for now. Great. We can’t start this as a GSoC project unless we have a reasonably clear view of what needs to be implemented. We must not end up re-discussing the general design once the coding period has started. There are still a number of open issues, so it’s important to refine that. Thanks, Ludo’.
Re: [patch] - Packaging guideline documentation update
Pierre-Antoine Rault p...@rigelk.eu skribis: Cross-refs and a small glossary would help a lot to start with Guix. However, I was thinking about an explanation of folders, sub folders and main files as seen in the GNUnet manual [1]. [1] https://gnunet.org/book/export/html/37 Sure. Again part of the information is already in the manual, but it’s scattered in different places. So an improvement would be to have an overview section that would reference to the relevant sections. Ludo’.
Re: [GNUnet-developers] [GSoC] GNUnet binary distribution system
On 03/11/2014 12:19 AM, Pierre-Antoine Rault wrote: The initial discussion [0] left open the question of where binaries themselves should be stored. A possibility would be to use GNUnet’s DHT simply as a discovery mechanism, and then to establish a connection directly to the user’s machine, which would run, say, an HTTP server. That's what I had in mind. Now, considered the post [2] by Christian Grothoff, we might consider using either an HTTP server for performance or GNUnet's MESH for anonymity (and security). We should balance needs and ease of implementation. Just to clarify here, I never said MESH would give you anonymity. I only said it should give you better NAT traversal and better authenticity and confidentiality than TLS/HTTPS (largely because you avoid the CA mess). Good anonymity will require more than MESH, and for Guix I am not sure that having anonymity is necessary (it might of course be fine to have that as an option in the future). 0x48426C7E.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [GSoC] GNUnet binary distribution system
Pierre-Antoine Rault p...@rigelk.eu writes: On 11/03/2014 04:35, Mark H Weaver wrote: FWIW, I think it might be worthwhile to support BitTorrent magnet links as well, as a middle ground between these two extremes. Most users will not be able to host binaries via HTTP; even if they have a server, the bandwidth requirements are hard to predict and likely to be too high. I'm not sure to understand why you precise BitTorrent magnet links. Magnet is a de-facto standard that is independant from BitTorrent [3] [4], I specified BitTorrent because it would presumably simplify our implementation to support only one protocol. and using BitTorrent in our case wouldn't have better performance than GNUnet's MESH. Okay. My suggestion was based on a guess that GNUnet's more ambitious goals (e.g. providing anonymity) would entail a significant performance cost compared with BitTorrent. If that's not the case, then I see no reason to use BitTorrent. I'd certainly prefer to support GNUnet. Thanks, Mark
