Staging branch is OPEN
Guix, The 'staging' branch is awaiting your patches. Please submit your changes by the end of this week (i.e. before Monday, 2019-12-15). Thanks, Marius signature.asc Description: PGP signature
Re: Feedback from JRES in Dijon
Hi Ludo, >> I am working on an article (ultimately for "Computing in Science and >> Engineering") that takes up some of those subjects and illustrates them >> using Guix. It would be nice to get feedback from the Guix community >> early, to make sure I don't do something stupid. So I could do a first >> version for the Guix blog, and thus propose it here for review, >> and then make it a bit less technical for a wider audience. > > That would be great! Also, a “how to do reproducible science with Guix” > hands-on would be nice (we could also have a section in the cookbook.) Since I am working for something quite similar for the Reproducible Research MOOC, I can also make a variant for the cookbook. I just need to find the time to make progress on all that! Cheers, Konrad.
Checking in, and an announcement!
Hello all! At risk of being lampooned by RMS if he is reading this mailing list, my wife and I had our first baby delivered last evening! We are very excited, and quite exhausted. I just wanted to thank you all who have reached out to me over Email, IRC, and Telegram. I _have_ received your message but I am waiting to respond. Unfortunately, I do not think I can anticipate participating in Guix Days / FOSDEM2020. But I am so thrilled to be a more integral member of the Guix project, and I hope you all are mostly satisfied with my work so far. I use Guix at my job, so it is nice getting paid (in a way) to play around with Guix. I have so much I am looking forward to helping with, but for now I am going to take a few days to rest and enjoy our little member of the GNU/Family, Matteo. Thank you all again for the supportive messages, and I will respond ASAP! Brett Gilio
Re: qt-build-system: prefix or suffix env-variables in wrap-program
Hartmut Goebel writes:
> Hi,
>
> it came to my mind that currently the qt-build-system wraps the program
> without passing along any environment variables. Thus e.g.
> XDG_CONFIG_DIRS will be overwritten, instead of not extended. Furtunatly
> ((guix build utils) wrap-program) supports prefixing or suffixing an
> existing variable value.
>
> Shall qt-build-system: prefix or suffix existing env-variables? Should
> it become
>
> export
> XDG_DATA_DIRS="$XDG_DATA_DIRS${XDG_DATA_DIRS:+:}/gnu/store/…-kate-…"
>
> or
>
> export
> XDG_DATA_DIRS="/gnu/store/…-kate-…${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS"
Note that XDG Base Directory Specification [1] sets default values to
use for empty or unset XDG_* variables, for instance:
"If $XDG_DATA_DIRS is either not set or empty, a value equal to
/usr/local/share/:/usr/share/ should be used."
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-…"
or
export
XDG_DATA_DIRS="/gnu/store/…-kate-…:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}"
[1] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
--
Mikhail
signature.asc
Description: PGP signature
Just found you
Good day I was emailing Richard Stallman and had a look at Gnu website, found Guix. I am a software developer, retired, and now working as a humanitarian in the field of software Development. I have my own Linux distribution based on Debian, Ubuntu and Mint, and my own programming language - Jade 5GL - that generates Python Gui code and provides a basis for fast-tracking python development of Gui applications. These two products represent about eight man years development. I last issued a version based on Ubuntu 16 Linux Mint 17, and I am now researching the next base for the next version. It seems that Guix is "Just in time". I am very concerned about the take-over of the Linux Desktop by the Multinational Cartel headed by AT And especially the sandboxing via Flatpak and Snap. I am hoping to install Guix soon and start to come to grips with it. If there is anyone working at packaging this at a higher level, like Ubuntu does with Debian, or mint with Ubuntu, then I would be interested in working from a more developed distribution. If not, I will see how it is possible to make Guix into a better Ubuntu/LInux Mint using my Jade 5GL to fast track the gui development. Perhaps you can put me in touch with any suitable developments? My own interest is specifically Linux on the Desktop, which I fully achieved in 2018, the year of Linux on the Desktop. Unfortunately, I did not have the resources to give it to the community it was intended for, and that may well turn out to be a good thing if, as may well be, I decide to cast Mint and Ubuntu to the waves and put my efforts fully into Guix, which looks to be most deserving and made for something new and great. Thanks for building it. Hopefully they all will come. Best wishes Adam of Bremen-Krubally Eisenach Germany and Hereford, UK. -- Sent from Adam's Tardis
Re: Packaging Jami progress
Okay, thanks. I'll use the second way then. I could also create a new file - jami-utils.scm and use it as a module, but a file containing only one procedure isn't good either. On Tue, 10 Dec 2019 18:43:58 -0600 Caleb Ristvedt wrote: > Jan Wielkiewicz writes: > > > I tried both ways - the second works, but the first doesn't. > > That would be the "in theory, it would work" part. On further > investigation, source-module-closure has a #:select? keyword > argument, which takes a module name and returns #f if it shouldn't be > included in the closure. By default it's 'guix-module-name?', so it > only includes the guix modules, and not, for example, (gcrypt hash). > One might try passing #:select? (const #t), but this would likely > reveal further issues - for example, guile-gcrypt doesn't work > without libgcrypt, but source-module-closure isn't going to pull that > in. > > The short answer is "yeah, for big closures that reach outside of > guix (or especially that have non-scheme dependencies) > source-module-closure isn't perfect", and build-side code should try > to minimize the size of the closure it pulls in (which, for pretty > much any (gnu packages ...) module, is going to be huge). The second > solution is probably the better one here. > > There's this sort of awkward middle ground we don't see much where a > build-side procedure has to be specific to some relatively small set > of packages, but still to enough packages that repeating it in the > builder for each of those packages duplicates a lot of code. Splicing > the definition into the builder programmatically is a bit of a hack, > as it's still duplicated between each builder interned in the store, > but much better than copy+pasting manually. > > Hope that helps. > > - reepca Jan Wielkiewicz
wrap-program –> wrap-script
Hi Guix, I’ve just pushed a change to use wrap-script in one package. The purpose of wrap-script is to wrap an executable without having to create a separate wrapper shell script. It does this by prepending a Guile script to the top of the file, which sets the environment variables and then re-executes itself with the target interpreter (e.g. Python). I noticed two things: 1) wrap-script does not automatically pull in Guile as a dependency, so if Guile isn’t among the inputs it will create a bad shebang. This should be fixed on core-updates. 2) we aren’t using wrap-script anywhere. I think a good use case would be the Python build system’s “wrap” phase where we currently use wrap-program. Most of the time we’d be dealing with Python scripts, so using wrap-script would be more appropriate here. What do you think? -- Ricardo
RE: guix gc doesn't seem to clean old guix revision
> Hi Yoann, Hi Ludo, > I had not understood that. I guess the patch below fixes it, I’ll push > t shortly. > Thanks, > Ludo’. Look great, but IMO, your addition, "(passwd:name (getpwuid (getuid", should be the only way to get the username since $USER and $LOGNAME could be overridden or unset. I don't always do it in my own scripts, but it is better to do not relay on env vars when you want something to be bulletproof. Since there is "passwd:dir pw", $HOME could be replaced with it too. Thanks, Yoann
qt-build-system: prefix or suffix env-variables in wrap-program
Hi,
it came to my mind that currently the qt-build-system wraps the program
without passing along any environment variables. Thus e.g.
XDG_CONFIG_DIRS will be overwritten, instead of not extended. Furtunatly
((guix build utils) wrap-program) supports prefixing or suffixing an
existing variable value.
Shall qt-build-system: prefix or suffix existing env-variables? Should
it become
export
XDG_DATA_DIRS="$XDG_DATA_DIRS${XDG_DATA_DIRS:+:}/gnu/store/…-kate-…"
or
export
XDG_DATA_DIRS="/gnu/store/…-kate-…${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS"
Currently affected variables are:
XDG_DATA_DIRS
XDG_CONFIG_DIRS
QT_PLUGIN_PATH
QML_IMPORT_PATH
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
