Re: ‘gnu: Add go-github-com-niemeyer-pretty.’
On Sun, Mar 06, 2022 at 03:32:09PM +0100, Maxime Devos wrote: > > + (define-public go-github-com-niemeyer-pretty > > + (package > > +(name "go-github-com-niemeyer-pretty") > > +(version "0.0.0-20200227124842-a10e7caefd8e") > > +(source > > + (origin > > +(method git-fetch) > > +(uri (git-reference > < + (url "https://github.com/niemeyer/pretty;) > > + (commit (go-version->git-ref version > > Why package the fork niemeyer/pretty instead of upstream kr/pretty? > Also, where does this version number come from? Looking at pkg.go.dev, > the version number is 0.3.0, not 0.3.0-$foo-$bar. The package is one of the dependencies for one of the dependencies of gitea. That said, Upon double-checking that package¹² it doesn't seem that it actually needs it directly, and when I comment out the package go-github-com-go-git-go-billy-v5 builds just fine, and so does my copy of gitea. Looks like this package isn't needed after all. ¹ github.com/go-git/go-billy/v5 ² https://github.com/go-git/go-billy/blob/v5.3.1/go.mod -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Packages for old Emacs versions
Hello Philip, Philip Kaludercic writes: > reading [0], I would like to ask if there is any interest in > up-streaming the work I have been doing to build old versions of Emacs > using Guix (the main use-case is to help with testing Emacs packages on > various versions)[1]? This is a very interesting use of Guix! > My fear is that with further upstream development, > there might be conflicts between the packages I inherit from (emacs, > emacs-no-x, emacs-minimal) and the packages I have definined in [1]. > An easy fix might be to not rely on the upstream package definitions, > but I am not certain if there are any down-sides I haven't considered. > > Of course, if the Guix project isn't interested in providing old > versions of packages, then I will continue look into maintaining my own > channel. I don’t have much experience with the Guix projects and its preferences and practices, so I can’t tell if it would be interested or not, unfortunately. I just wanted to mention that if not, another upstreaming option could be the Guix-Past channel: https://gitlab.inria.fr/guix-hpc/guix-past -- Thanks Thiago
Re: License issue with SRFI 5
Hi, On Monday, March 7, 2022 5:41:46 AM EST Ludovic Courtès wrote: > Hi, > > Philip McGrath skribis: > > To start with that, my proposed approach, which I hope satisfies the > > FSDG, is here: https://github.com/racket/srfi/pull/15 > > Good to know; I hope the next Racket release will include it. > Yes! It's been merged upstream, so it will be in 8.5 (and snapshots, meanwhile), and we've included it in Guix as of the recent update to Racket 8.4. -Philip signature.asc Description: This is a digitally signed message part.
Re: Building clang with gcc-toolchain@11
On Mon, Mar 7, 2022 at 5:18 AM Ludovic Courtès wrote: > The ‘clang’ definition reads: > > ;; Use a sane default include directory. > (string-append "-DC_INCLUDE_DIRS=" > (assoc-ref %build-inputs "libc") > "/include") > > What happens if we don’t pass that option, or if we pass > “-DC_INCLUDE_DIRS=/no-such-directory”? > > It might work because C_INCLUDE_PATH already contains libc’s include > directory; that way, we’d no longer rely on the “libc” label, which is > what prevents use of ‘--with-c-toolchain’ here. > "libc" is also referenced in the set-glibc-file-names phase. Why, even when using a different version of the same toolchain, is "libc" not available in %build-inputs? Shouldn't the following "--with-c-toolchain" leave the build unmodified (with gcc@10 currently the default compiler)? Yet I still see the same error as when switching the gcc-toolchain version. --8<---cut here---start->8--- $ ./pre-inst-env guix build clang --with-c-toolchain=clang=gcc-toolchain@10 substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% The following derivation will be built: /gnu/store/h7dw73yclv6i5wi9pf7gw44lnkvzwgp3-clang-13.0.1.drv building /gnu/store/h7dw73yclv6i5wi9pf7gw44lnkvzwgp3-clang-13.0.1.drv... Backtrace: 14 (primitive-load "/gnu/store/5sw2i4ljmsdg7nsscihb7i32mm8?") In ice-9/eval.scm: 214:21 13 (_ #f) 217:50 12 (lp (# ?)) 217:50 11 (lp (# ?)) 217:50 10 (lp (# ?)) 217:50 9 (lp (# ?)) 217:50 8 (lp (# ?)) 217:50 7 (lp (# ?)) 217:50 6 (lp (# ?)) 217:50 5 (lp (# ?)) 217:50 4 (lp (# ?)) 217:50 3 (lp (# ?)) 217:33 2 (lp (# ?)) 202:51 1 (_ #f) In unknown file: 0 (string-append "-DC_INCLUDE_DIRS=" #f "/include") ERROR: In procedure string-append: In procedure string-append: Wrong type (expecting string): #f builder for `/gnu/store/h7dw73yclv6i5wi9pf7gw44lnkvzwgp3-clang-13.0.1.drv' failed with exit code 1 build of /gnu/store/h7dw73yclv6i5wi9pf7gw44lnkvzwgp3-clang-13.0.1.drv failed View build log at '/var/log/guix/drvs/h7/dw73yclv6i5wi9pf7gw44lnkvzwgp3-clang-13.0.1.drv.bz2'. guix build: error: build of `/gnu/store/h7dw73yclv6i5wi9pf7gw44lnkvzwgp3-clang-13.0.1.drv' failed --8<---cut here---end--->8---
Re: Package's inputs for developer?
On Mon, 07 Mar 2022, Kaelyn wrote: > On Sunday, March 6th, 2022 at 8:19 AM, Olivier Dion via "Development of GNU > Guix and the GNU System distribution." wrote: > >> Hi Guix, >> >> I often find my self using inheritance of package to add native-inputs >> >> that are not stricly necessary for building the project, but are used >> >> for developement purpose like so: >> >> - >> >> (define base-native-inputs (list ...)) >> >> (define my-package >> >> (package >> >> ... >> >> (native-inputs base-native-inputs) >> >> ...)) >> >> ;; Developers version >> >> (package >> >> (inherit my-package) >> >> (native-inputs >> >> (append base-native-inputs >> >> (list gdb lcov >> >> - >> >> I guess this is the correct way of doing it or perhaps I should put gdb >> >> and lcov in the base-native-inputs?. But I was thinking that perhaps >> >> something like `(developer-inputs (list gdb lcov))` would be better, >> >> since these inputs are not stricly necessary for building the package. > > Can you give a bit more detail about what the use case is for adding > developer tools as inputs? Only for convenience of developing. I also use the developer inputs for continuous integration for generating coverage report for example. I guess that all of this can be wrapped under a script such as `development-env` and use `guix shell` in it. > The inheritance you describe seems more cumbersome than simply doing > `guix shell gdb lcov -D my-package` to enter a development environment > with gdb and lcov present, while also being a bit more limited when > there are multiple tools with a similar function. In the above > example, imagine if a developer wants to debug my-package using lldb > instead of gdb--the developer-inputs would require transforming the > package definition, but the ad-hoc invocation could simply be `guix > shell lldb lcov -D my-package`. I agree it's not very flexible. I basically impose the usage of GDB for debugging here. I guess that using `guix shell` is the correct way of doing so then. Regards, old -- Olivier Dion Polymtl
Re: Package's inputs for developer?
Hello, On Sunday, March 6th, 2022 at 8:19 AM, Olivier Dion via "Development of GNU Guix and the GNU System distribution." wrote: > Hi Guix, > > I often find my self using inheritance of package to add native-inputs > > that are not stricly necessary for building the project, but are used > > for developement purpose like so: > > - > > (define base-native-inputs (list ...)) > > (define my-package > > (package > > ... > > (native-inputs base-native-inputs) > > ...)) > > ;; Developers version > > (package > > (inherit my-package) > > (native-inputs > > (append base-native-inputs > > (list gdb lcov > > - > > I guess this is the correct way of doing it or perhaps I should put gdb > > and lcov in the base-native-inputs?. But I was thinking that perhaps > > something like `(developer-inputs (list gdb lcov))` would be better, > > since these inputs are not stricly necessary for building the package. Can you give a bit more detail about what the use case is for adding developer tools as inputs? The inheritance you describe seems more cumbersome than simply doing `guix shell gdb lcov -D my-package` to enter a development environment with gdb and lcov present, while also being a bit more limited when there are multiple tools with a similar function. In the above example, imagine if a developer wants to debug my-package using lldb instead of gdb--the developer-inputs would require transforming the package definition, but the ad-hoc invocation could simply be `guix shell lldb lcov -D my-package`. Cheers, Kaelyn > > Regards, > > old > > -- > > Olivier Dion > > Polymtl
Re: License issue with SRFI 5
Hi, Philip McGrath skribis: > To start with that, my proposed approach, which I hope satisfies the > FSDG, is here: https://github.com/racket/srfi/pull/15 Good to know; I hope the next Racket release will include it. Thank you, Ludo’.
Re: better error messages through assertions
Hi Philip, Philip McGrath skribis: > Racket's state-of-the-art contract system has many features and nuances. I *do > not* think anyone should try to implement them all in one fell swoop. I'm > hoping there's a way to implement your simple assertions with only a modest > amount of overhead that will provide the right base on which to grow the rest > of a contract system. In the short term, the advantage over: > >> (assert-type (listof service?) services >> "SERVICES must be a list of values.") > > is that you don't have to write error messages by hand. > > You need two types of values: > > 1. Contracts, recognized by `contract?`; and > 2. Blame objects, recognized by `blame?`. [...] Thanks for the explanation and references! I had briefly looked at Racket’s contract API in the past but your message gave a clearer view of how this all fits together. > I would love to have contracts in Guix, even very rudimentary contracts. If > it's something the community more generally would be interested in, I'd be > glad to help as much as I can. It’d be great to benefit from your expertise here. Like you wrote, I think we should start with a simple contract system, certainly simpler than Racket’s, and build from there. If you’re willing and able to spend time prototyping this, that’s great. :-) Thanks, Ludo’.
Re: Building clang with gcc-toolchain@11
Hi, Greg Hogan skribis: > I'd like to instead use the latest gcc-toolchain (currently gcc-toolchain@11) > and have clang-toolchain built with that gcc-toolchain. No matter what > I offer in the "--with-c-toolchain" or "--with-input" options I always see > the following error regarding '(assoc-ref %build-inputs "libc")' evaluating > as false, even when specifying "--with-c-toolchain=clang=gcc-toolchain@10" > that should currently be in use by default. Any ideas for fixing this? The ‘clang’ definition reads: ;; Use a sane default include directory. (string-append "-DC_INCLUDE_DIRS=" (assoc-ref %build-inputs "libc") "/include") What happens if we don’t pass that option, or if we pass “-DC_INCLUDE_DIRS=/no-such-directory”? It might work because C_INCLUDE_PATH already contains libc’s include directory; that way, we’d no longer rely on the “libc” label, which is what prevents use of ‘--with-c-toolchain’ here. HTH, Ludo’.
