Re: Package request inxi
Oleg Pykhalovwrites: > Yes, unfortunately ‘inxi’ doens't provide like a ‘./configure’ thing to > discover and use inputs. But we could patch paths to input binaries. My point that the dependencies are not _needed_ during the build phase, so getting all the inputs induces extra load for nothing for the builder. -- Pierre Neidhardt My way of joking is to tell the truth. That's the funniest joke in the world. -- Muhammad Ali signature.asc Description: PGP signature
Re: Package request inxi
Pierre Neidhardtwrites: > I'm running into a strange issue: > Line 4506: > > $item =~ > s/chipset|components|computing|computer|corporation|communications|electronics|electrical|electric|gmbh|group|incorporation|industrial|international|nee|revision|semiconductor|software|technologies|technology|ltd\.||\bltd\b|inc\.||\binc\b|intl\.|co\.||corp\.||\(tm\)|\(r\)|®|\(rev > ..\)|\'|\"|\sinc\s*$|\?//gi; > > gets replace by > > > $item =~ > s/chipset|components|computing|computer|corporation|communications|electronics|electrical|electric|gmbh|group|incorporation|industrial|international|nee|revision|semiconductor|software|technologies|technology|ltd\.||\bltd\b|inc\.||\binc\b|intl\.|co\.||corp\.||\(tm\)|\(r\)|??|\(rev > ..\)|\'|\"|\sinc\s*$|\?//gi; > > More precisely, > > ® > > into > > ?? > > I use the trivial build system and the only substitute (for now) is > >(substitute* "inxi" > (("/usr/bin/env perl") > (string-append (assoc-ref %build-inputs "perl") "/bin/perl"))) Please, could you try to wrap a ‘substitute*’ procedure with: (with-fluids ((%default-port-encoding #f)) (substitute* #;…)) Oleg. signature.asc Description: PGP signature
Re: Package request inxi
Pierre Neidhardtwrites: > Oleg Pykhalov writes: > >> Instead you could use ‘(inputs …)’ and ‘(native-inputs …)’ which will >> not be installed to a user's profile but available in build phases. > > But those dependencies won't be used during the build phase Yes, unfortunately ‘inxi’ doens't provide like a ‘./configure’ thing to discover and use inputs. But we could patch paths to input binaries. Oleg. signature.asc Description: PGP signature
Re: Package request inxi
I'm running into a strange issue: Line 4506: $item =~ s/chipset|components|computing|computer|corporation|communications|electronics|electrical|electric|gmbh|group|incorporation|industrial|international|nee|revision|semiconductor|software|technologies|technology|ltd\.||\bltd\b|inc\.||\binc\b|intl\.|co\.||corp\.||\(tm\)|\(r\)|®|\(rev ..\)|\'|\"|\sinc\s*$|\?//gi; gets replace by $item =~ s/chipset|components|computing|computer|corporation|communications|electronics|electrical|electric|gmbh|group|incorporation|industrial|international|nee|revision|semiconductor|software|technologies|technology|ltd\.||\bltd\b|inc\.||\binc\b|intl\.|co\.||corp\.||\(tm\)|\(r\)|??|\(rev ..\)|\'|\"|\sinc\s*$|\?//gi; More precisely, ® into ?? I use the trivial build system and the only substitute (for now) is (substitute* "inxi" (("/usr/bin/env perl") (string-append (assoc-ref %build-inputs "perl") "/bin/perl"))) -- Pierre Neidhardt There's no real need to do housework -- after four years it doesn't get any worse. signature.asc Description: PGP signature
Re: Package request inxi
Oleg Pykhalovwrites: > Instead you could use ‘(inputs …)’ and ‘(native-inputs …)’ which will > not be installed to a user's profile but available in build phases. But those dependencies won't be used during the build phase: it's unnecessary load for the builder. -- Pierre Neidhardt He is a man capable of turning any colour into grey. -- John LeCarre signature.asc Description: PGP signature
Re: Package request inxi
Hello Pierre, Pierre Neidhardtwrites: > I'm trying to package inxi. Thank you for working on this! Let us know if you have more questions. > Does guix support optional dependencies? Unfortunately Guix doesn't. Instead you could use ‘(inputs …)’ and ‘(native-inputs …)’ which will not be installed to a user's profile but available in build phases. > Or is it that I should just include them in the description? ‘(package (description #;…) #;…)’ is not a good place to list and track dependencies, because a package could include more or less in future. Oleg. signature.asc Description: PGP signature
Re: Package request inxi
I'm trying to package inxi. Does guix support optional dependencies? Or is it that I should just include them in the description? -- Pierre Neidhardt I think that's easier to read. Pardon me. Less difficult to read. -- Larry Wall in <199710120226.taa06...@wall.org> signature.asc Description: PGP signature
Re: How to install prerelease package versions (particularly Emacs)
Oleg Pykhalovwrites: > Pierre Neidhardt writes: > >> I tried reusing your package snippet from >> http://lists.gnu.org/archive/html/help-guix/2017-09/msg00074.html by >> setting >> >>(url "git://localhost/~ambrevar/projects/emacs") > > I'm sorry for probably an obvious question. Does ‘git clone > git://localhost/~ambrevar/projects/emacs’ work? > > […] > >> I'm not very familiar with the "git" protocol: does it require some >> special configuration? > > It does, see > https://www.gnu.org/software/guix/manual/html_node/Version-Control-Services.html > > Be sure ‘user-path’ is setted correctly. > >> I also tried specifying a local path: >> >>(url "/home/ambrevar/projects/emacs") >> >> […] >> >> I think this is a bug: if git clone accepts local paths, then so should >> git-reference. > > It would be a useful feature, but I don't know all pitfalls. > > We can do ‘guix pull --url=$PWD’ in “Guix checkout” though. Thank you for the hint. That said, I really don't want to set up a git server for so little. Is there a good reason not to allow local paths in git URLs? -- Pierre Neidhardt Every solution breeds new problems. signature.asc Description: PGP signature
Re: How to install prerelease package versions (particularly Emacs)
Oleg Pykhalovwrites: >>> In case of ‘emacs’ package recipe, ‘--with-source’ doesn't work for a >>> snapshot of the ‘master’ branch. >> >> Why? Because you’d need to run ‘autoreconf’ and the like? > > To run everything in ‘(arguments …)’ except ‘#:parallel-build? #t’. > > From http://lists.gnu.org/archive/html/help-guix/2017-09/msg00074.html > --8<---cut here---start->8--- > (arguments >(substitute-keyword-arguments >`(#:parallel-build? #t >#:tests? #f >,@(package-arguments emacs)) > ((#:phases phases) > `(modify-phases ,phases > (add-after 'unpack 'autogen >(lambda _ > (zero? (system* "sh" "autogen.sh" > (delete 'reset-gzip-timestamps) > --8<---cut here---end--->8--- What do you mean? That parallel-build has to be turned off for the master branch? I actually noticed that running `make -j5` locally, the build fails at the `temacs` step. The build succeeds with `make`. That said, I tried running guix build --keep-failed --with-source=ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-26.1-rc1.tar.xz emacs It fails with starting phase `check' make -C lib all make info-real info-dir You do not seem to have the test/ directory. Maybe you are using a release tarfile, rather than a repository checkout. make: *** [Makefile:937: have-tests] Error 1 make: *** Waiting for unfinished jobs Why should it fail if it's a tarball? The error message seems that it understands precisely what we are trying to do. -- Pierre Neidhardt Being overloaded is the sign of a true Debian maintainer. signature.asc Description: PGP signature
Re: How to install prerelease package versions (particularly Emacs)
Mathieu Lirzinwrites: > With the ‘#:recursive?’ keyword option set to #t, ‘local-file’ should > work for directories. Indeed, thanks for pointing out. I tried and it failed with starting phase `configure' source directory: "/tmp/guix-build-emacs-dev-26.0.91.drv-0/source" (relative from build: ".") build directory: "/tmp/guix-build-emacs-dev-26.0.91.drv-0/source" configure flags: ("CONFIG_SHELL=/gnu/store/icz3hd36aqpjz5slyp4hhr8wsfbgiml1-bash-minimal-4.4.12/bin/bash" "SHELL=/gnu/store/icz3hd36aqpjz5slyp4hhr8wsfbgiml1-bash-minimal-4.4.12/bin/bash" "--prefix=/gnu/store/iaipasvi8dys79ms3y0axvwwdfnd31dq-emacs-dev-26.0.91" "--enable-fast-install" "--build=x86_64-unknown-linux-gnu") configure: WARNING: unrecognized options: --enable-fast-install ./configure: line 3350: config.log: Permission denied ./configure: line 3360: config.log: Permission denied phase `configure' failed after 0.1 seconds I inspected the content of "/tmp/guix-build-emacs-dev-26.0.91.drv-0/source": many files are missing, among others "configure". I am very confused... -- Pierre Neidhardt signature.asc Description: PGP signature
Re: `guix package -u` upgrades packages to themselves
On 11.04.2018 11:40, Pierre Neidhardt wrote: > > Sorry if I was confusing: the output remains the same after upgrade. > > I can repeat the command indefinitely, it keep "upgrading" the same set > of packages as per the output (but it does not actually do anything). > I see the same on 792ddfdc76147d494052fa93ecbfdbee7e72be68. -- GPG: 7FDE 7190 2F73 2C50 236E 403D CC13 48F1 E644 08EC [13:56:45]pi@pi:~/code/updapr$ guix package -u guile: warning: failed to install locale warning: failed to install locale: Invalid argument The following package will be upgraded: guile2.2.3 -> 2.2.3 /gnu/store/nb39n4ia25fdmzcfm628il1jqdkipf7s-guile-2.2.3 substitute: guile: warning: failed to install locale substitute: warning: failed to install locale: Invalid argument nothing to be done [14:19:21]pi@pi:~/code/updapr$ ll ~/.guix-profile/bin/guile lrwxrwxrwx 5 root root 65 Jan 1 1970 /home/pi/.guix-profile/bin/guile -> /gnu/store/nb39n4ia25fdmzcfm628il1jqdkipf7s-guile-2.2.3/bin/guile* [14:20:29]pi@pi:~/code/updapr$ guix package -u guile: warning: failed to install locale warning: failed to install locale: Invalid argument The following package will be upgraded: guile2.2.3 -> 2.2.3 /gnu/store/nb39n4ia25fdmzcfm628il1jqdkipf7s-guile-2.2.3 substitute: guile: warning: failed to install locale substitute: warning: failed to install locale: Invalid argument nothing to be done [14:21:18]pi@pi:~/code/updapr$ ll ~/.guix-profile/bin/guile lrwxrwxrwx 5 root root 65 Jan 1 1970 /home/pi/.guix-profile/bin/guile -> /gnu/store/nb39n4ia25fdmzcfm628il1jqdkipf7s-guile-2.2.3/bin/guile* signature.asc Description: OpenPGP digital signature
Re: `guix package -u` upgrades packages to themselves
Pierre Neidhardtwrites: > I can run the following command as much as I want it will keep updating > a bunch of packages to themselves. That’s expected if you’ve upgraded Guix since installing the packages. (If you haven’t then it’s probably a bug.) That’s because the package version itself is insufficient. In Guix we’re dealing with package “variants”. Guix will never upgrade a package to the same variant, but it can happen that there are different variants for the same version of a package. That’s usually because inputs to these packages have changed, which results in a new package output in the functional package management model. The version stays the same, but since the inputs have changed, the output will be different and thus end up in a new directory. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net