Re: Guix to participate in the Google Summer of Code
Chris Marusich writes: > Ricardo Wurmus writes: > >> Garbage collection in the context of Guix is not very difficult to >> understand. The garbage collector may remove any item that has zero >> users; the link count on a store item is indicative of the number of >> users that item has. For garbage collection you essentially go through >> all items and check if the link count is zero. […] > It looks like, in nix/libstore/gc.cc, we basically walk the references > graph starting from the GC roots and delete anything that can't be > reached from a root. Yes, this is more accurate. Thanks for the correction. (Link counts only matter for deduplication.) -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: Talk about Guix and GuixSD at FSF Hungary
2018-02-20 9:37 GMT+01:00 Gábor Boskovits : > 2018-02-18 14:22 GMT+01:00 Ricardo Wurmus : > >> >> Hi Gábor, >> >> > On february the 20. at 18:00 local time I will give a talk about Guix >> and >> > GuixSD for the Hungarian FSF community. >> >> That’s great! >> >> > I based the style of my talk on one given by Ludo. I Left the copyright >> > notices intact, only adding my name. I hope this is the right thing to >> do, >> > but I would like to hear your opinon. >> >> This seems to be the correct way to do this. >> >> > One more thing, I am willing to add the source of this talk to the >> > maintainers repo. What is the right way to do that? Who should I >> contact? >> >> The repository is here: >> >> http://git.savannah.gnu.org/cgit/guix/maintenance.git/ >> >> Usually, it’s just a matter of adding a new directory containing the >> sources. You can send a URL to the sources (e.g. as a tarball) to >> guix-devel; we would download them from there and add the sources to the >> maintenance repo. >> >> > Thanks for the information. I uploaded the tarball to here: > https://ufile.io/hsft0 > Thanks for all your help. The talk went well, they asked me to repeat it on the Free Software Conference on the 12. of May. > > >> -- >> Ricardo >> >> GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC >> https://elephly.net >> >> >> >
Re: Guix to participate in the Google Summer of Code
Hi Alex, >> The reference scanner is already implemented in the form of grafts. The >> code opens each file and searches efficiently for store references. >> > Does this mean we have procedure to do a single find-reference and the > remaining work is to build a recursive find-reference? The current way to obtain references is through the daemon. In (guix store) there is a procedure “references” that is used whenever we want to get a list of references for a store item. But how does the daemon itself obtain those references in the first place? “nix/libstore/references.cc” implements a reference scanner and it is quite similar to how “replace-store-references” in (guix build graft) works. So a first step towards an implementation of the reference scanner would be to liberate “replace-store-references” from its grafting context; possibly turn it into a higher order function that finds references and optionally invokes a function when a reference is found. Then it could be used for grafting as well as for collecting references in the daemon. But I would recommend to revive the work from the last GSoC first. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: emacs-25.3 aborted
I don't know what caused this, but something between Guix 0.14.0-6.0dcf675 and 0.14.0-8.bc880f9 forced my own computer attempt to build Emacs, and resulted in a working Emacs version. Store path name differences for Emacs: - Old (working): b1nbgnpifkisz4szmasxrwzqlgqagy8w-emacs-25.3 - New (self-built, working): lh66vaxq3da6m8yz83lvgny4f4bwh760-emacs-25.3
Re: 01/04: gnu: htop: Fix tree view.
On Wed, Feb 21, 2018 at 09:49:19AM -0500, Tobias Geerinckx-Rice wrote: > nckx pushed a commit to branch master > in repository guix. > > commit 79f0561f43cc62dd332007cd847c0ad2870b3afc > Author: Tobias Geerinckx-Rice > Date: Wed Feb 21 06:06:46 2018 +0100 > > gnu: htop: Fix tree view. > > * gnu/packages/patches/htop-fix-process-tree.patch: New file. > * gnu/local.mk (dist_patch_DATA): Add it. > * gnu/packages/admin.scm (htop)[source]: Use it. Thanks for taking care of this! Can you make sure to report the problem upstream? signature.asc Description: PGP signature
Re: 01/04: gnu: htop: Fix tree view.
Leo, On 2018-02-21 17:59, Leo Famulari wrote: Thanks for taking care of this! Can you make sure to report the problem upstream? +From: Tobias Geerinckx-Rice +I will investigate further... ;-) Kind regards, T G-R Sent from a Web browser. Excuse or enjoy my brevity.
Re: Staging
On Tue, Feb 20, 2018 at 04:54:36AM +0100, Marius Bakke wrote: > Leo Famulari writes: > > > There are some patches on the staging branch, including an update to the > > time zone database. > > > > What are the plans for the next week or so? Should we try merging the > > staging branch in that timeframe? > > Yes, let's start this in a few days, when Hydra calms down. Unless something comes up, I'll start an evaluation of the staging branch tomorrow. signature.asc Description: PGP signature
Re: PYTHONPATH woes
Hi, thanks for raising the PYTHONPATH issue. Looks like we have a major problem here. Am 20.02.2018 um 11:53 schrieb Ricardo Wurmus: > I don’t know why this happens. I find it puzzling that in this > particular case the user’s profile contains an *older* version of > statsmodels (0.6.1). The wrapper includes the correct version of > statsmodels (0.8.0) in the PYTHONPATH. Here’s the backtrace: You are addressing three issues here: 1) Why is the older package imported, where the newer one is expected to be first in path? 2) We are mixing Python2 and Python3 paths 3) Is the way we use PYTHONPATH in the wrapper the correct way? re 1): This is extremely curious: Why is the older package imported, where the newer one is expected to be first in path? To analyze this in detail, please make a copy of the resp. wrapper script and change the last command into: exec -a "$0" python3 -m site and run the changed wrapper. This should show all paths defined in the wrapper first. If this does not give any insight, change it into exec -a "$0" python3 -v -c "import statsmodels" and then exec -a "$0" python3 -v -c "import ribodiff.estimatedisp" and try to find some insight there. re 2): As soon as Python2 and Python3 are installed in the same profile, we put both site-packages for both versions into PYTHONPATH, which obviously is wrong. $ PYTHONPATH= guix environment --ad-hoc python@2 python […] [guix] $ echo $PYTHONPATH /gnu/store/jkwp041kjy6li85n66ymxkfrr0hr2psj-profile/lib/python2.7/site-packages:/gnu/store/jkwp041kjy6li85n66ymxkfrr0hr2psj-profile/lib/python3.5/site-packages: A simple work-around would be to make the profile a (pseudo) virtual environment, which is a easy as creating a file "/gnu/store/…-profile/pyvenv.cfg". This will trigger a mechanism in site.py to insert /gnu/store/…-profile/lib/pythonX.Y/site-packages" into sys.path - for the current python version only! Try it: sudo touch $GUIX_ENVIRONMENT/pyvenv.cfg $ PYTHONPATH= guix environment --ad-hoc python@2 python […] [guix] $ PYTHONPATH=/tmp/foo:/tmp/bar python3 -m site […] '/gnu/store/…-profile/lib/python3.5/site-packages', re 3) When running PYTHONPATH=/tmp/foo:/tmp/bar python -m site on e.g. Debian, one can see that the order in sys.path is as follows: - $PWD - $PYTHONPATH elements - built-in paths (e.g. /usr/lib64/python3.5) - site-packages The idea seems to be that PYTHONPATH can overwrite all packages, but site-package can not. This can be seen as if in the wrapper-scripts we are not using PYTHONPATH as indented: The user can not overwrite site-packages. We ought to think if this is what we want, as this is how Python works. Depending on the result of the analysis for (1) and if we implement (2), we can investigate how to solve (3). One idea I already looked at this evening is to replace the wrappers by a minimal virtualenv. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: bug#30537: glibc 2.26 refuses to run on CentOS 6.8
Hi Ricardo,
Ricardo Wurmus writes:
> Ricardo Wurmus writes:
>
>> Here’s a patch to graft the glibc to apply the patch to allow the 2.6.32
>> kernel. I’m going to apply this at work now.
>
> That patch had a couple of problems. Here’s a new version.
[...]
> diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
> index b2c1d232f..111bbbcec 100644
> --- a/gnu/packages/base.scm
> +++ b/gnu/packages/base.scm
> @@ -12,6 +12,7 @@
> ;;; Copyright © 2017 Mathieu Othacehe
> ;;; Copyright © 2017 Marius Bakke
> ;;; Copyright © 2017 Eric Bavier
> +;;; Copyright © 2018 Ricardo Wurmus
> ;;;
> ;;; This file is part of GNU Guix.
> ;;;
> @@ -537,6 +538,7 @@ store.")
> ;; Note: Always use a dot after the minor version since various places
> rely
> ;; on "version-major+minor" to determine where locales are found.
> (version "2.26.105-g0890d5379c")
> + (replacement glibc-2.26-patched)
> (source (origin
> (method url-fetch)
> (uri (string-append "https://alpha.gnu.org/gnu/guix/mirror/";
> @@ -839,10 +841,20 @@ GLIBC/HURD for a Hurd host"
> ;; Below are old libc versions, which we use mostly to build locale data in
> ;; the old format (which the new libc cannot cope with.)
>
> +(define glibc-2.26-patched
> + (package
> +(inherit glibc)
> +(replacement #f)
> +(source (origin
> + (inherit (package-source glibc))
> + (patches (cons (search-patch "glibc-allow-kernel-2.6.32.patch")
> + (origin-patches (package-source glibc
> +
> (define-public glibc-2.25
>(package
> (inherit glibc)
> (version "2.25")
> +(replacement #f)
> (source (origin
>(inherit (package-source glibc))
>(uri (string-append "mirror://gnu/glibc/glibc-"
> @@ -862,6 +874,7 @@ GLIBC/HURD for a Hurd host"
>(package
> (inherit glibc)
> (version "2.24")
> +(replacement #f)
> (source (origin
>(inherit (package-source glibc))
>(uri (string-append "mirror://gnu/glibc/glibc-"
> @@ -882,6 +895,7 @@ GLIBC/HURD for a Hurd host"
>(package
> (inherit glibc)
> (version "2.23")
> +(replacement #f)
> (source (origin
>(inherit (package-source glibc))
>(uri (string-append "mirror://gnu/glibc/glibc-"
> @@ -905,6 +919,7 @@ GLIBC/HURD for a Hurd host"
>(package
> (inherit glibc)
> (version "2.22")
> +(replacement #f)
> (source (origin
>(inherit (package-source glibc))
>(uri (string-append "mirror://gnu/glibc/glibc-"
These (replacement #f) fields should not be needed. 'replacement' is
now an 'innate' field of the package record type, which means that it is
not inherited.
> diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
> index 7286e954c..db43691fd 100644
> --- a/gnu/packages/commencement.scm
> +++ b/gnu/packages/commencement.scm
> @@ -4,6 +4,7 @@
> ;;; Copyright © 2012 Nikita Karetnikov
> ;;; Copyright © 2014, 2015, 2017 Mark H Weaver
> ;;; Copyright © 2017, 2018 Efraim Flashner
> +;;; Copyright © 2018 Ricardo Wurmus
> ;;;
> ;;; This file is part of GNU Guix.
> ;;;
> @@ -486,7 +487,7 @@ the bootstrap environment."
>;; built just below; the only difference is that this one uses the
>;; bootstrap Bash.
>(package-with-bootstrap-guile
> - (package (inherit glibc)
> + (package/inherit glibc
> (name "glibc-intermediate")
> (arguments
>`(#:guile ,%bootstrap-guile
> @@ -664,7 +665,7 @@ exec ~a/bin/~a-~a -B~a/lib -Wl,-dynamic-linker -Wl,~a/~a
> \"$@\"~%"
>
> (define glibc-final
>;; The final glibc, which embeds the statically-linked Bash built above.
> - (package (inherit glibc-final-with-bootstrap-bash)
> + (package/inherit glibc-final-with-bootstrap-bash
> (name "glibc")
> (inputs `(("static-bash" ,static-bash-for-glibc)
>,@(alist-delete
We seem to be oscillating on the question of whether to graft these
early GLIBCs. In June 2017, I switched to using 'package/inherit' here
in commit 13f7f2fd2b208c29361ef2290f55911879a6adf2, and in October those
changes were reverted in commit 848f550f2c105326dc3be4033c8aaf35ec21cde4
by Efraim, although I'm not sure why.
It'll be painful to have *everything* grafted until the next
core-updates cycle, but I suppose it's necessary.
Thanks,
Mark
