Re: Our package names should not include "github-com"
On Mon, Oct 16, 2017 at 05:38:43PM -0400, Leo Famulari wrote: > Using the domain name as part of the *upstream* library name is useful > for upstream authors because of how Go's built-in dependency management > tools work. Go integrates dependency management into the language and > the `go` tool itself. Re-using the upstream library name is useful > because they have already disambiguated for us. > > I don't intend to be rude, but I'm not going to put much effort into > responding to further comments that are not based on knowledge of how Go > handles package / dependency management with its built-in tools, or > modular programming in Go, in general. Already I used tons of my free > time to learn this stuff, just so I could make Guix packages of Go > software. Please meet me where I am. > > Again, I don't see an ethical problem here, so any motivation for me to > participate in this discussion, as a volunteer, must be technical. If > it's *wrong* to name the packages in this way, I will behave > differently. I replied too harshly here, and I apologize for that. For me, this conversation really started on the wrong foot. signature.asc Description: PGP signature
Cuirass HTTP API
Leo Famulari skribis: > On Mon, Oct 16, 2017 at 02:56:38PM +0200, Ludovic Courtès wrote: >> From the maintainer’s viewpoint, it just stresses that we must keep >> going with the efforts to improve our build infrastructure. Currently >> that has only benefited x86, but perhaps now is a good time to plug our >> ARM boxes behind berlin.guixsd.org, for a start. >> >> Thoughts? > > What sort of interface do we have for querying berlin.guixsd.org's > evalutions (to borrow the Hydra term)? > > Is it just `guix weather`, or is there some sort of historical > continuous integration view as with the Hydra interface? Thanks to Mathieu Othacehe, Cuirass now supports a subset of the HTTP API of Hydra. Currently the only interface to that is Emacs-Guix, but we could/should write JavaScript code that does that; any takers? :-) So currently we can do: M-x guix-hydra-latest-builds … and from there browse builds, view their status, etc. We have yet to add support for viewing build logs (!) to ‘guix publish’ and/or Cuirass. > For all the frustrations with Hydra, it's still invaluable to be able to > compare evaluations and look at things like "newly failing jobs", and to > share hyperlinks with each other. Agreed. We’re not there yet, but that’s not insurmountable. BTW, there’s the possibility of a master’s or internship project at the MDC (Berlin, DE) with Ricardo around Cuirass: http://bioinformatics.mdc-berlin.de/mastersprojects.html I may also be able to recruit a master student or an intern at Inria (Bordeaux, FR), possibly to work in this area. If anyone is interested, please let us know! Ludo’.
Re: Our package names should not include "github-com"
Hello, Leo Famulari writes: > On Mon, Oct 16, 2017 at 05:38:43PM -0400, Leo Famulari wrote: >> Using the domain name as part of the *upstream* library name is useful >> for upstream authors because of how Go's built-in dependency management >> tools work. Go integrates dependency management into the language and >> the `go` tool itself. Re-using the upstream library name is useful >> because they have already disambiguated for us. >> >> I don't intend to be rude, but I'm not going to put much effort into >> responding to further comments that are not based on knowledge of how Go >> handles package / dependency management with its built-in tools, or >> modular programming in Go, in general. Already I used tons of my free >> time to learn this stuff, just so I could make Guix packages of Go >> software. Please meet me where I am. >> >> Again, I don't see an ethical problem here, so any motivation for me to >> participate in this discussion, as a volunteer, must be technical. If >> it's *wrong* to name the packages in this way, I will behave >> differently. > > I replied too harshly here, and I apologize for that. For me, this > conversation really started on the wrong foot. I agree this conversation could have been more cheerful! I understand your irritation; let me use this opportunity to thank you for your hard work and time spent working on bringing Go to Guix! There seems to be interesting solutions built with Go. I'm trying to rectify my ignorance of the Go system; I've started reading about Go but haven't gone so far yet to be able to answer my question in a definitive way. I'll keep reading! I've seen that Debian is also using the repo names in their go packages naming scheme, so there must be some good to it. Maxim
Re: Android build-tools / prebuild / soong
Hello Hartmut! Hartmut Goebel writes: > Hi, > > maybe somebody want to work in this puzzle :-) > > Last week I played around upgrading the android libs and tools to the > current release 8.0.0_r17, when I realized that the build-system has > switched from a Makefile-base to one based on "Android.mk" files. These > are meant to be processed by a tool called "soong" (with two `o`). > > soong is based on "ninja" an "Blueprint". There are no > build-instructions and no usage examples. So I asked on the > android-building mailinglist how to build and use soong stand-alone. I > got the answer that this is not indented but to be build like this > (fixed by my): > > guix environment --ad-hoc repo > repo init -u https://android.googlesource.com/platform/manifest -b > build-tools > repo sync -j32 > mkdir OUT > OUT_DIR=OUT prebuilts/build-tools/build-prebuilts.sh > > So the script in the last line is the key. It looks acceptable, but I > have no clue about how go programs are build normally. So for me solving > this puzzle is quite time-consuming and I may not be able to work on it > for quite some time. Anybody to take over? Interesting findings! I took a look at those Android.mk files when I studied our package of adb (in which we are currently using our own independent makefile instead of the Android.mk), but couldn't make sense of them. It seems that Soong is not meant to work with those .mk files though; its page talks about newer JSON-like "Android.bp" files that supersede the older make-based Android.mk files[1]. It would be nice to have an Android build system which could take those already made makefiles and build the packages with them; it would remove the burden of maintaining our own set and enable packaging more Android stuff (I have fastboot on my todo). [1] https://android.googlesource.com/platform/build/soong/
