Re: (Really) Free Software future in the light of systemd
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] Please forgive my delay. Regarding HyperbolaBSD: We do list non-GNU free distros in https://gnu.org/distros/. The distro developers have to make the same pledge. If they want this, they should contact us as it says in https://gnu.org/distros/. However, GNU package maintainers do not have a responsibility to support a non-GNU system in any particular way. That responsibility is limited to the GNU system. -- Dr Richard Stallman Founder, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi, > 4. if neither ad-hoc nor inputs-of present then > a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour, > b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the > new behaviour. One remark: I suggest the test to be "set to a non-empty string" resp. "unset or empty". This is the way many programs to such checks. In shell this would be `[ -n "$VAR" ] ` and `[ -n "$VAR" ]`. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Guix mirror: sourceware discussion report
zimoun writes: > Well, how many people have a physical access to the MDC infrastructure? > How many people are currently working for the MDC institute? > To my knowledge, only Ricardo. > So what will happen if Ricardo "leaves" (long vacation, change of job, > bus attack, etc.). Mădălin also has physical access. -- Ricardo
Re: qt-build-system: prefix or suffix env-variables in wrap-program
Am 11.12.19 um 21:25 schrieb Mikhail Kryshen:
> So the correct way to extend XDG_DATA_DIRS would be
>
> export
> XDG_DATA_DIRS="${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}:/gnu/store/…-kate-…"
I'm quite confident, adding /usr/share etc. here as default would be
wrong from a guix point of view: This would break isolation of
environments. On a foreign distribution this would even give the foreign
distribution's installation precedence over guix's.
Anyway: Let me ask my question differently: Should the user be able to
*overrule* or only to *extend* guix's installation?
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
signature.asc
Description: OpenPGP digital signature
Re: NLNet grant "Next Generation Internet -- Search & discovery": I'm in!
zimoun writes: > Well, thirdly I also think that Guix lacks tools to navigate in its > Git history. Now we have "guix time-machine", it appears to me that > finding specific package back in the history is complicated (basically > git checkout+git log+grepouch! not user-friendly). I think that the Guix Data Service could be used to answer questions like that, so it would make sense to implement a way to talk to it from the Guix command line. -- Ricardo
Re: Guix mirror: sourceware discussion report
Hi Tobias, On Fri, 13 Dec 2019 at 19:39, Tobias Geerinckx-Rice wrote: > I've replied on IRC as well, apologies if I repeat myself. :-) It is hard to follow everything that is said on IRC. ;-) And times to times, IMO, it is necessary to report back on guix-devel what was said: the community is then aware and it is recorded (so searchable in the future if needed). > zimoun 写道： > > Currently "guix pull" from Savannah and issues can arise. As we > > recently experimented. Tobias and Ricardo recently discussed how > > to > > mirror the repo. IMHO, it is a good idea to mirror but not a > > good idea > > to locate it on Ricardo infrastructure, again. :-) > > I disagree. > > I think berlin is the best place to create a simple ‘main’ mirror > at this point in time. It's a simple git one-liner to keep it up > to date. In the extremely unlikely event that it breaks, many > people can fix it. Ricardo works hard but isn't responsible for > all of Berlin on his own. I agree on these lines. And we are talking about a service (mirror) easy to deploy elsewhere. But... obviously a but. :-) Correct me if I am wrong, currently, Guix mainly depends on: - the FSF guys for the main repo (Savannah) located in US. - the MDC institute located in Germany. - the build farm (Cuirass instance): ci.guix.gnu.org - the storage of substitutes (even it is mitigated with CDN) - the Mumi front-end of Debbugs: issues.guix.gnu.org - Boards here and there (Julien and now Pierre, Andreas, etc.) Well, how many people have a physical access to the MDC infrastructure? How many people are currently working for the MDC institute? To my knowledge, only Ricardo. So what will happen if Ricardo "leaves" (long vacation, change of job, bus attack, etc.). Guix should not put all the eggs in the same basket, IMHO. Therefore, this tiny service (mirror) should done elsewhere than on the machines located in Berlin. As a simple first step. > > Well, I propose to see if we can mirror on sourceware.org which > > are > > GNU friends. ;-) > > > > I took the liberty to contact them on IRC. See below. > > > > What I see is: we still "guix pull" from Savannah as usual. > > Then if Savannah is down, we catch the error and we try > > (transparently > > for the user) the sourceware url. > > By ‘we’, you mean the ‘guix pull’ command itself, correct? Yes. Sorry. Too passionate. ;-) > Something akin to > > (channel > (name 'guix) > (url (list "https://savannah…; >"https://sourceware…;)) > …) > > ? Yes. Or built-in. Whatever. Even, talking about that, a official list of Git mirrors should be maintained and included in the manual or cookbook or website or you-name-it. > I'd like to see that added to the channels.scm format for selfish > reasons. I understand and I do not have any strong opinion. :-) Even, the channels.scm seems better than hard-coded. > However, I'd still like the first or second URL to start with > ‘guix.gnu.org’. I have nothing against Sourceware, but > guix.gnu.org has been pretty solid (AFAIK) and, more importantly, > does not require users to trust yet another party by default. I agree. I am not expert but can mirror.guix.gnu.org point to a machine located elsewhere than Berlin? > [‘Trustable Guix pull’ rears its head again :-) …] +1 > > As a first contact, they agree on the principle. Even they ask > > numbers > > about traffic etc. :-) > > I know that about 1,000 unique IPs requested substitutes on Berlin > during the month of November. Thank you for this number. Interesting. > You'll have to ask Savannah for the git stats (roughly how many > IPs ran ‘guix pull’), which may wildly differ (but I doubt that). I will. :-) Thank you. All the best, simon
TeX Live 2019 wanted
Greetings Guix, The latest version of the popular Poppler PDF library (slated for the 'core-updates' branch) unsurprisingly[0][1][2] breaks 'texlive-bin'. Previously we were able to rely on the work of other distributions, but most have moved on to 2019 by now. And the required changes now are more intrusive than previously. The main problem is that LuaTeX upstream has removed the Poppler dependency entirely in favor of a smaller library, so no upstream fixes are available: https://github.com/TeX-Live/texlive-source/commit/aa5363bd0dc180752c7d8eb9d847c2581e453b1a I *believe* this commit should be safe to backport as it predates the 2019 changes in the affected directories, but that requires some work too. It would be much better to update the shebang to 2019. Ricardo, do you think you'll have time for a TeX Live 2019 update in the coming weeks? If not, could you outline the required changes for enterprising Guix contributors? TIA! [0] https://git.savannah.gnu.org/cgit/guix.git/commit/?id=143fc1a591c552b0464674cfebf8de63bdde7461 [1] https://git.savannah.gnu.org/cgit/guix.git/commit/?id=9df397508dc1bc3544534aebc7c658c9754b08b4 [2] https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c078f1b08b844c7126db2a4a0f83db2217e3bb0f signature.asc Description: PGP signature
Re: NLNet grant "Next Generation Internet -- Search & discovery": I'm in!
> I'm happy to let your know that my application to the NLNet "Next > Generation Internet -- Search & Discovery" grant for Guix has been > accepted! Great, congratulations! :-) > 1. Parameterized packages >(Previous discussion: > https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00285.html) I've been looking for something like this. I want to run a more minimal system like I used to with Parabola GNU/Linux. I often find Guix's packages to be too heavy and hard to modify without a lot of effort. Package inheritance is itself easy to accomplish with Guile code but getting the modified package to build successfully is sometimes difficult. It would certainly help if Guix had pre-parameterized packages that one could modify easily. However, this can enormously increase the burden on Guix packagers. However, we can discuss that later when we have more specific proposals. > 2. File search >(Previous discussion: > https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00236.html) This feature would be very nice too. Currently, I fall back to one of my Parabola GNU/Linux installations, and run pkgfile there to get an approximate idea of what Guix package a certain file might be in. signature.asc Description: PGP signature
Re: NLNet grant "Next Generation Internet -- Search & discovery": I'm in!
Hi Pierre, Congrats! On Fri, 13 Dec 2019 at 15:49, Pierre Neidhardt wrote: > 2. File search >(Previous discussion: > https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00236.html) Yes, it is really lacking. For example, if one wants to use the 'hg' control version system, then one will naively search "guix search hg" and this will return "Human Genome" packages (useful in bioinformatics stuff). Worse, because the description/synopsis of the package which provides the command 'hg' do not mention the term 'hg', it is impossible to reach it if one does not know that it is provided by the very package mercurial. So, what I am personally doing is: DuckDuckGo, look at some Debian packages and hope it is the same name in Guix. Ouch! And it is super useful to find headers. You have a code with "#include " and it is hard to know which Guix package provides this very header 'name-it.h'. However, IMHO, the "filesearch" should be included in the "search" command and not another command. I mean: guix package --file-search=hg or guix search hg --file-search It appears to me a better UI than adding again another subcommand. :-) > 5. Social integration with the Guix catalogue > >Previous discussions: >- Adding wikidata, wikipedia & screenshot-url fields to > package-recipes: > https://lists.gnu.org/archive/html/guix-devel/2018-11/msg7.html >- Re-approaching package tagging: > https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00385.html >- New library: guile-wikidata: > https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00107.html >- Guix <-> Wikidata: > https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00017.html >- Guix Wikidata module - next steps: > https://lists.gnu.org/archive/html/guix-devel/2019-01/msg00089.html > >There were also a few discussions regarding package search improvements, in >which has Zimoun participated quite a bit if I recall correctly. Feel free >to share all your precious links! :) Firstly, IMHO tagging, i.e., assign a specific word belonging to a set of words, is not a good approach. My main argument is: the set of words is arbitrary, and at the end, it is bikeshedding and/or it is not really useful because it is not self-organised by the data themselves. As a Debian user, I do not use their tag system; and I am almost sure they have documented the "usefulness" of their tagging system and the feedback (I have in mind talks in DebConf but I am not able to find it now). However, grouping packages by similar topic is important for discoverybility. The question is: how is the grouping done? Instead of a manual tagging, I propose to first compare clustering methods based on synopsis+description and Natural Language Processing (NLP). It is what I had in mind when I answered to the thread "Re-approaching package tagging" but life intervened and I did nothing on this front. Well, the Python ecosystem provides nice packages (most not yet in Guix last time I checked) to ease the first exploratory and see if it will pay off or not. Not about tagging but close enough to be maybe relevant: https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00133.html https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00252.html Secondly, instead of manual tagging, I propose to work on the relevance scoring. Basically, "guix search" should act as a recommendation system IMHO. Then the questions are: where is done the indexing computations? locally? by the Guix Data Service and "guix pull" will fetch this index? Can be merge with other distro or upstream (CRAN, github) via wikidata or API? etc. Well, thirdly I also think that Guix lacks tools to navigate in its Git history. Now we have "guix time-machine", it appears to me that finding specific package back in the history is complicated (basically git checkout+git log+grepouch! not user-friendly). I have tried to describe use cases in this message. https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00513.html IMO, something similar to "git tag" should be added (in "guix pull"?). But one can also think to integrate such historical information in Wikidata and for example "guix search emacs --all" will return all the versions and commits present in Guix, then it is easy to run "guix time-machine --commit=1234 -- install emacs". Kind of such ideas... and not fully clear in my mind. ;-) Last about UI: https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00289.html Currently "guix search" supports regexp but part of the filtering is done by recsel. And I do not find that handy. Hope that these words make sense. Cheers, simon
Re: Cross-compilation broken on canonical packages.
Small mistake sorry. This fails: --8<---cut here---start->8--- guix build --target=aarch64-linux-gnu -e "((@ (gnu packages base) canonical-package) (@ (gnu packages base) grep))" --8<---cut here---end--->8--- while this succeeds: --8<---cut here---start->8--- guix build -e "((@ (gnu packages base) canonical-package) (@ (gnu packages base) grep))" --8<---cut here---end--->8--- Mathieu
Cross-compilation broken on canonical packages.
Hello, This command fails: --8<---cut here---start->8--- guix build -e "((@ (gnu packages base) canonical-package) (@ (gnu packages base) grep))" --8<---cut here---end--->8--- with this output: --8<---cut here---start->8--- building /gnu/store/nlq0iw749hnyy7nk3cq6pjwqkxv437ca-make-boot0-4.2.1.drv... starting phase `set-SOURCE-DATE-EPOCH' phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds starting phase `set-paths' environment variable `PATH' set to `/gnu/store/36zgy21hfy185nmdgj87ll6q4hj5riiw-gcc-cross-aarch64-linux-gnu-7.4.0/bin:/gnu/store/4d68mhjjwqc95lyrm63yrsnrlqzkbpyr-binutils-cross-aarch64-linux-gnu-2.32/bin' environment variable `CROSS_LIBRARY_PATH' set to `/gnu/store/pgg0nxh1l39dybb5pwqyskb9qxqz57r9-glibc-mesboot-2.16.0/lib:/gnu/store/p0s4wym402gsnqzicr87zrli43dvfbms-binutils-mesboot-2.20.1a/lib:/gnu/store/bb6s2y6121pxvhwyr1n6dg7pwj88bsbj-gcc-mesboot-4.9.4/lib:/gnu/store/p5r7gprzg774vq8l94924m598i86ryya-glibc-cross-aarch64-linux-gnu-2.29/lib:/gnu/store/z86g7zwj2mdl1328qpgmim262sppjxqp-glibc-cross-aarch64-linux-gnu-2.29-static/lib' environment variable `CROSS_CPATH' set to `/gnu/store/pgg0nxh1l39dybb5pwqyskb9qxqz57r9-glibc-mesboot-2.16.0/include:/gnu/store/p0s4wym402gsnqzicr87zrli43dvfbms-binutils-mesboot-2.20.1a/include:/gnu/store/bb6s2y6121pxvhwyr1n6dg7pwj88bsbj-gcc-mesboot-4.9.4/include:/gnu/store/bp1ap2whzmwvh2myj31hfmg9pi4sly0r-linux-libre-headers-bootstrap-0/include:/gnu/store/p5r7gprzg774vq8l94924m598i86ryya-glibc-cross-aarch64-linux-gnu-2.29/include:/gnu/store/f3izsng5fzwh6zf2z7aaj5v04jp5hmcy-linux-libre-headers-cross-aarch64-linux-gnu-4.19.56/include' environment variable `GUIX_LOCPATH' unset environment variable `C_INCLUDE_PATH' set to `/gnu/store/36zgy21hfy185nmdgj87ll6q4hj5riiw-gcc-cross-aarch64-linux-gnu-7.4.0/include' environment variable `CPLUS_INCLUDE_PATH' set to `/gnu/store/36zgy21hfy185nmdgj87ll6q4hj5riiw-gcc-cross-aarch64-linux-gnu-7.4.0/include' environment variable `LIBRARY_PATH' set to `/gnu/store/36zgy21hfy185nmdgj87ll6q4hj5riiw-gcc-cross-aarch64-linux-gnu-7.4.0/lib' environment variable `C_INCLUDE_PATH' set to `/gnu/store/36zgy21hfy185nmdgj87ll6q4hj5riiw-gcc-cross-aarch64-linux-gnu-7.4.0/include' phase `set-paths' succeeded after 0.0 seconds starting phase `install-locale' warning: failed to install 'en_US.utf8' locale: Invalid argument phase `install-locale' succeeded after 0.0 seconds starting phase `unpack' In execvp of tar: No such file or directory command "tar" "xvf" "/gnu/store/cr04i9xi5nbkn7lqb1nnxkqvpwy92m78-make-4.2.1.tar.xz" failed with status 127 builder for `/gnu/store/nlq0iw749hnyy7nk3cq6pjwqkxv437ca-make-boot0-4.2.1.drv' failed with exit code 1 build of /gnu/store/nlq0iw749hnyy7nk3cq6pjwqkxv437ca-make-boot0-4.2.1.drv failed View build log at '/var/log/guix/drvs/nl/q0iw749hnyy7nk3cq6pjwqkxv437ca-make-boot0-4.2.1.drv.gz'. cannot build derivation `/gnu/store/xpb7jhgjghxy624gz7rfy5zb8rsdri3i-grep-3.3.drv': 1 dependencies couldn't be built guix build: error: build of `/gnu/store/xpb7jhgjghxy624gz7rfy5zb8rsdri3i-grep-3.3.drv' failed --8<---cut here---end--->8--- This is topic has already been discussed here[1][2]. Usually I work around it by passing "--no-grafts" or avoiding canonical-packages. Now that cross compiling a system is possible, avoiding canonical packages is hard (used in %base-packages and "system" derivation). Any ideas where to start on this problem? Thanks, Mathieu [1]: https://guix-devel.gnu.narkive.com/LsByvXrK/cross-building-bootstrap-binaries-fail-in-current-master#post5 [2]: https://lists.gnu.org/archive/html/bug-guix/2017-10/msg00101.html
Re: NLNet grant "Next Generation Internet -- Search & discovery": I'm in!
Pjotr Prins writes: > That is great news Pierre :) Indeed! Happy times! :D -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
