Re: Move r-{desolve, quadprog, pracma, subplex} from maths.scm to cran.scm
Hi Ricarco On Fri, 22 Nov 2019 at 15:47, Ricardo Wurmus wrote: > PS: I also think that CRAN things in bioinformatics.scm should be moved > to cran.scm, and even some or all of the R stuff in statistics.scm. > (Same applies to Bioconductor packages, which should end up in > bioconductor.scm where possible.) I am working on that. Let consider some quick stats with "grep". 1. Currently, the file bioconductor.scm contains 4 packages with 'cran-uri' and git blames you. :-) Well, the 4 commits are: : a207bca2ad gnu: r-codedepends: Move from cran to bioconductor. : 3a0babacdc gnu: Add r-htscluster. : 7ed869f796 gnu: Add r-nbpseq. : 80eb01c776 gnu: r-gkmsvm: Move to (gnu packages bioconductor). with some comments as --8<---cut here---start->8--- ;; This is a CRAN package, but it uncharacteristically depends on a ;; Bioconductor package --8<---cut here---end--->8--- Do you remember a special motivation? 2. The second point is that the file statistics.scm contains 227 packages and 206 are cran-uri. And the file cran.scm already contains 602 packages, so it will be almost as python-xyz.scm is. Why not. Then, this file statistics.scm will be almost empty and I propose instead to populate the files maths.scm, python-xyz.scm. What do you think? 3. It is a big move. Do you prefer - a commit per package, so more or less 300 commits? - or a commit bioconductor.scm->cran.scm, another statistics.scm->cran.scm, bioinformatics.scm->bioconductor.scm and bioconductor->bioinformatics.scm, etc.? Thank you for your insights. All the best, simon
Re: Packaging Jami progress
Dnia 2019-12-05, o godz. 15:32:23
Pierre Neidhardt napisał(a):
> - To call a custom function from the builder, you need to include the
> module that defines it for the build system, e.g.
>
> (arguments
> `(#:modules ((gnu packages telephony)
> ,@%gnu-build-system-modules)
> ...)
>
Tried luck with the procedure, but it seems I can't provide the module
I'm currently in to the "arguments" field - Guile said it couldn't find
code for the module: "no code for module (gnu packages jami)". I mean
in the jami.scm file, defining (gnu packages jami) module,
I can't give this module as an argument.
(arguments
`(#:modules ((gnu packages jami)
,@%gnu-build-system-modules)
...)
By the way, I decided to move all Jami packages, procedures and
dependencies modified by the patches to a separate file -
jami.scm. It'll be much easier to maintain in this way.
The full error message:
The following derivation will be built:
/gnu/store/an28ny48d6iyfn79j2fhqk7mvd6jmahq-pjproject-jami-2.9.drv
building
/gnu/store/an28ny48d6iyfn79j2fhqk7mvd6jmahq-pjproject-jami-2.9.drv...
Backtrace: 10 (primitive-load "/gnu/store/dj185gjiag94gk1clrj0158xcal?")
In ice-9/eval.scm:
721:20 9 (primitive-eval (begin (use-modules (gnu # jami) # ?) ?))
In ice-9/psyntax.scm:
1262:36 8 (expand-top-sequence ((begin (use-modules (gnu ?) ?) ?)) ?)
1209:24 7 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
1209:24 6 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
285:10 5 (parse _ (("placeholder" placeholder)) (()) _ c&e (eval) ?)
In ice-9/boot-9.scm:
3377:20 4 (process-use-modules _)
222:17 3 (map1 (((gnu packages jami)) ((guix build #)) ((# ?)) ?))
3378:31 2 (_ ((gnu packages jami)))
2803:6 1 (resolve-interface _ #:select _ #:hide _ #:prefix _ # _ ?)
In unknown file:
0 (scm-error misc-error #f "~A ~S" ("no code for modu?" ?) ?)
ERROR: In procedure scm-error:
no code for module (gnu packages jami)
Is there some kind of "this" for the module in guile I could use in
order to be able to invoke the jami-apply-dependency-patches procedure?
I exported it correctly using #:export (jami-apply-dependency-patches).
Jan Wielkiewicz
Re: Overhauling the cargo-build-system
On 2019-12-09 04:45, Chris Marusich wrote:
> input in order to actually build the program. In this model, I guess
> every "*-src" package would have no inputs and just one output. I guess
> any package that produces an artifact, for example the "ripgrep"
> package, would list a bunch of "*-src" packages as inputs: one for every
> crate in the transitive closure of dependencies and dev-dependencies of
> the ripgrep crate. That might solve the problem of cyclic dependencies,
> and it might reduce (but not eliminate) the amount of excessive building
> performed by cargo-build-system. However, it would make some package
> definitions large, it would introduce duplication of inputs across
> packages that need the same "*-src" inputs, and it would create a lot of
> "*-src" packages. On the plus side, tools like "guix graph" would work
> as-is; currently, "guix graph" has not been taught to understand
> #:cargo-inputs and #:cargo-development-inputs for cargo-build-system
> packages.
I don't understand why just adding a (skip-build?) to the source rust
packages, dropping their cargo-dev-deps AND leaving the cargo-inputs for
all the rest of the dependencies wouldn't accomplish the same thing. The
thing I object to is having to specify the transient packages at the top
level, since that would be unusable for actually rust development. Is
there any problem with the following example for rust source packages?
(define-public rust-home
(package
(name "rust-home")
(version "0.5.1")
(source
(origin
(method url-fetch)
(uri (crate-uri "home" version))
(file-name
(string-append name "-" version ".crate"))
(sha256
(base32
"1a4wcnadw2sarmisb5bz7gs4qwnijalvbf5gf7kg0wdxyxa3jxd3"
(build-system cargo-build-system)
(arguments
`(#:skip-build?
#t
#:cargo-inputs
(("rust-scopeguard" ,rust-scopeguard)
("rust-winapi" ,rust-winapi
(home-page "https://github.com/brson/home";)
(synopsis
"Shared definitions of home directories")
(description
"Shared definitions of home directories")
(license (list license:expat license:asl2.0
(define-public rust-winapi
(package
(name "rust-winapi")
(version "0.3.8")
(source
(origin
(method url-fetch)
(uri (crate-uri "winapi" version))
(file-name
(string-append name "-" version ".crate"))
(sha256
(base32
"1ii9j9lzrhwri0902652awifzx9fpayimbp6hfhhc296xcg0k4w0"
(build-system cargo-build-system)
(arguments
`(#:skip-build?
#t
#:cargo-inputs
(("rust-winapi-i686-pc-windows-gnu"
,rust-winapi-i686-pc-windows-gnu)
("rust-winapi-x86-64-pc-windows-gnu"
,rust-winapi-x86-64-pc-windows-gnu
(home-page
"https://github.com/retep998/winapi-rs";)
(synopsis
"Raw FFI bindings for all of Windows API.")
(description
"Raw FFI bindings for all of Windows API.")
(license #f)))
Also see patch 38465
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38465) for a complete
example. I would like too know if there is an problem with this patch
to, before I start packaging the other rust programs this way.
Thanks,
-Martin
Re: ARM VM with networking support?
Hey ho! Mathieu Othacehe skribis: >> Here’s my tentative config file. > > I just generated a disk-image with your config file! Just like you, I did > hit the "unsupported ioctl" issue on both master and core-updates > branch. > > The reason is that the command run when producing the disk image is: > > qemu-arm qemu-system-arm disk-image-builder > ^ ^ > | |-- Native qemu (so for armhf-linux architecture). > | > Run by binfmt because qemu-system-arm is a binary for armhf > architecture. > > So a syscall issued somewhere in disk-image-builder goes through the > kernel emulated by qemu-system-arm and via qemu-arm to your host kernel. > > The failing syscall is number 47601 (FS_IOC32_GETVERSION), I don't know > why it is not supported by our host kernel. However, using a > qemu-system-arm built for arm doesn't make much sense here, because we > add an unecessary (and failing) layer of emulation. Woow, good catch! > So what I would propose is to produce a disk-image using a qemu-system-* > built for the host architecture (and not the system specified by > --system argument). This remains true when cross-compiling a system. Indeed, makes sense. > The attached patch does thin in an ugly way but that solves the issue. […] > +(define-record-type > + (%native-qemu qemu system) > + native-qemu? > + (qemu native-qemu-qemu) > + (system native-qemu-system)) > + > +(define-gexp-compiler (native-qemu-compiler (native-qemu ) > system target) > + (package->derivation (native-qemu-qemu native-qemu) > + (native-qemu-system native-qemu))) > + > (define* (expression->derivation-in-linux-vm name exp > #:key > (system (%current-system)) > target > @@ -193,6 +204,9 @@ made available under the /xchg CIFS share." > (reboot) > (exit 1 > > + (define qemu-native > +(%native-qemu qemu (@ (guix config) %system))) > + >(let ((initrd (or initrd > (base-initrd file-systems > #:on-error 'backtrace > @@ -215,7 +229,7 @@ made available under the /xchg CIFS share." > (gnu build vm)) > >(let* ((native-inputs > - '#+(list qemu (canonical-package coreutils))) > + '#+(list qemu-native (canonical-package coreutils))) This is a clever hack, but now the result of: guix system build -s armhf-linux -d … would be dependent on the actual system type. In other words, the result would be different if you run it on armhf-linux, if you run it on x86_64-linux, or if you run it on i686-linux. Not great. Could we use an evil trick, like the ‘binfmt-misc?’ predicate we discussed in another thread, to somehow strip one emulation layer? Hmm probably not possible… Why do we have that syscall ID mismatch anyway?… Thoughts? Ludo’.
Re: Store channel specification in profile
Ludovic Courtès writes: > This is exactly what’s currently implemented if you look at > ~/.guix-profile/manifest, under ‘provenance’. But does "provenance" tell about the channels? > Like zimoun writes, it would be nice to have some sort of a “describe” > command for a regular profile. Actually maybe “guix describe -p”? > > Actually ‘guix describe -p ~/.guix-profile’ works but doesn’t display > anything useful. We could fix that by recognizing the kind of profile, > somehow. Seems like a good idea. How do we define "anything useful" though? The provenance of packages? How would we format it? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: articles on Elm and Guix
Hi! Robert Vollmert skribis: > I wrote a series of articles related to my Elm packaging for Guix: > > https://vllmrt.net/spam/guix-elm-1.html > https://vllmrt.net/spam/guix-elm-2.html > https://vllmrt.net/spam/guix-elm-3.html I’m late to the party, but I too find it real nice, both as an introduction to Guix hacking and as an example of how to use Guix throughout up to application deployment. Thanks for sharing! Ludo’.
Re: Store channel specification in profile
Hi! Konrad Hinsen skribis: >> One question arises though: channel specifications only make sense for >> profiles generated with manifests. > > Not even for those, if the manifest uses inferior-packages. I'd go for > per-package channel specifications. They could be optimized (more > compact, more efficiently usable) by first storing a list of all > distinct channels and then a (package . channels) list. This is exactly what’s currently implemented if you look at ~/.guix-profile/manifest, under ‘provenance’. Like zimoun writes, it would be nice to have some sort of a “describe” command for a regular profile. Actually maybe “guix describe -p”? Actually ‘guix describe -p ~/.guix-profile’ works but doesn’t display anything useful. We could fix that by recognizing the kind of profile, somehow. Thoughts? Ludo’.
Re: Status of Gnome upgrade?
Hi, Yay! We already have Gnome 3.32 on master! Unfortunately, I've found one regression on XFCE/LXDE, as libwnck-2 does not build anymore. I've open a bug report[1] with the proposed patch, sorry I didn't noticed it sooner, but I haven't run a full reconfiguration on my old machine with the branch integrated until it has been in master. Best regards, Miguel [1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=38547
