From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Famulari Subject: Re: Several questions on Guix(SD) Date: Mon, 22 Aug 2016 17:49:21 -0400 Message-ID: <20160822214921.GA9557@jasmine> References: <20160822225350.32c08923@alma-ubu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44014) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bbx69-0008VC-Kq for help-guix@gnu.org; Mon, 22 Aug 2016 17:49:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bbx64-0003Jr-Lx for help-guix@gnu.org; Mon, 22 Aug 2016 17:49:37 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:51437) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bbx63-0003Hc-CX for help-guix@gnu.org; Mon, 22 Aug 2016 17:49:32 -0400 Content-Disposition: inline In-Reply-To: <20160822225350.32c08923@alma-ubu> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: =?iso-8859-1?Q?Bj=F6rn_H=F6fling?= Cc: Guix-Help Welcome, Björn! On Mon, Aug 22, 2016 at 10:53:50PM +0200, Björn Höfling wrote: > * Do you have the concept of package maintainers, like in Debian? > People who are responsible for each package, apply patches, etc? No, we don't have a concept of this. In practice, people pay attention to the packages they care about. This information can be obtained with `git blame` and `git log`. Some of us subscribe to security-related mailing lists, and apply security updates across the package tree. More people should do this, please :) > * Are there "recommmended"/"sugggested" dependencies? For example, > diffoscope complained that "'readelf' is not on the path. Falling > back to binary comparison." That could be a candidate for a package > not needed at compile/runtime but that would enhance the usage if > present. All dependencies are specified explicitly in the package definitions and the build systems. We do have a concept of run-time and build-time dependencies. See the text about "inputs": Speaking of caring about packages, I care about diffoscope. I will look into adding readelf to the diffoscope package definition. > * I have for example in my store: > * /gnu/store/abc...-tar-1.29/ > * /gnu/store/xyz...-tar-1.29/ > > Can I somehow figure out what's the differnce between them, how > they came into the system, which one is "newer"? I tried diffoscope > and found some marginal, crypted hex-differences. You can inspect the relationships a given store item has to other store items with the '--referrers', '--requisites', '--references' options to `guix gc`: I'm not sure if it's possible to go backwards from a store item to the Guix Git commit it was built from. Advice wanted! > * Can I somehow get a store history? I.e. a (ordered) list of > installation progress. "ls -ltr /gnu/store" was my first try > but it obviously fails. Yes, there is `guix package --list-generations`. For more, see > * Is there a log for the deamon? I only found the > "/var/log/guix/drvs", which seam to be only logs of each compilation. > BTW, what do the two letters of the subfolders mean? The log output of the daemon goes wherever your daemons normally log to. On most recent versions of the major distros, this is handled by systemd / journald. Package build logs can be obtained like so: `guix build foo --log-file --no-grafts` ... but you still have the problem of knowing which version of Guix produced the store item you are interested in. I'm interested to hear better answers to this question. > * Is there a list of builds available that are not reproducible? Or is > that (eq? _ '()) ? We don't have much infrastructure for tracking reproducible builds yet. Help wanted! We do have `guix challenge`, for challenging a binary substitute server. Also, packages can be built with '--rounds=x' and '--check', which repeat the build and compare the outputs to see if they are bit-for-bit identical. > * Are any other Hydra instances running other than the GNU ones that > could be challenged? I don't know of any public instances. There are some private instances running in institutional settings. There is `guix publish`, which is not a full continuous integration system like Hydra, but rather a simple HTTP server that you can use to serve your binary substitutes: > * If I would like to set up my own Hydra server, how much storage space > takes the whole hydra-archive of substitutes (for each platform)? Or > only the %base-packages? > > * How much time takes it to recompile all packages in Hydra? I don't know. Others can answer this. And, others can add to my answers as well.