Re: Profile hook in build environment?
Ricardo Wurmus skribis: > Guillaume Le Vaillant writes: > >> Is there a way to generate files and add them to the environment created >> by 'guix build' as it can be done with profile hooks? > > Yes, the build system can do whatever it wants. The > texlive-build-system, for example, builds a union directory from all TeX > Live inputs and then modifies the configuration file. Thanks for the pointer, it has been very useful. Pierre Neidhardt skribis: > Hi Guillaume, > > Thanks for taking a shot at this ;) > > Why would we need to generate the ASDF configuration file in a hook? > Can't we do it at build time? > > Cheers! I got rid of the hook and now I'm creating all the required files/links at build time in 'etc/common-lisp/source-registry.conf.d/' and in 'etc/common-lisp/asdf-output-translations.conf.d/'. It seems to work well with packages having simple definitions. Now I have to check and adapt the more complex ones. signature.asc Description: PGP signature
Re: Setuid programs
Hello, Christopher Lemmer Webber ezt írta (időpont: 2020. szept. 10., Cs, 0:52): > > Christopher Lemmer Webber writes: > > > Gábor Boskovits writes: > > > >> Hello, > >> > >> Christopher Lemmer Webber ezt írta (időpont: > >> 2020. szept. 9., Sze, 21:00): > >>> > >>> Maxim Cournoyer writes: > >>> > >>> > Hello Gabor! > >>> > > >>> > Gábor Boskovits writes: > >>> > > >>> >> Hello guix, > >>> >> > >>> >> I would like to propose an extension to how setuid programs are > >>> >> currently handled. The last time I checked it could only do setuid and > >>> >> setgid root. Some services, such as postfix need a more fine grained > >>> >> setuid setup. I would propose a record type, such as: > >>> >> (setuid > >>> >> (program setuid-program) > >>> >> (setuid setuid-setuid) > >>> >> (setgid setuid-setgid) > >>> >> (user setuid-user) > >>> >> (group setuid-group)) > >>> >> > >>> >> So that there is more fine grained control. > >>> >> > >>> >> I would also propose to move this to the services framework, so that > >>> >> services could extend this field on demand. > >>> >> > >>> >> Wdyt? > >>> > > >>> > This sounds great! I also encountered such limitation and tried to > >>> > fixing it in https://issues.guix.info/41763, with some success (and an > >>> > unresolved limitation pointed by Chriistopher) but I agree that using a > >>> > record makes more sense and is more future proof. > >>> > > >>> > Maxim > >>> > >>> I'm eager to use Postfix on Guix (maybe it's me, but I just can't make > >>> sense of the weird DSL that opensmtpd uses) so I guess if that's what's > >>> necessary it already makes it a good idea. > >>> > >>> However I don't fully understand the syntax of what you proposed. Let's > >>> see if I can guess with a fake entry > >>> > >>> #~(setuid > >>>;; The program to run, from the shady package > >>>(program (string-append #$shady "/bin/scaryfoo") > >>>;; Would this be a boolean? If so should it be `setuid?` > >> yes, this should be a bool, studi? looks good to me. > >>>(setuid setuid-setuid) > >>>;; Likewise? > >>>(setgid setuid-setgid) > >> yes, the same thing applies here. > >>>;; Presumably the use we want to set this to > >>>(user setuid-user) > >> yes, this should just be the uid of the owner > >>>;; Presumably the group we want to se this to > >> this should be the gid. > >>>(group setuid-group)) > >>> > >>> ... right? > >>> > >>> I guess this could be done in a backwards compatible way; > >>> %setuid-programs could either evaluate to strings or records, so the > >>> "simpler" version can remain an option? > >> Yes, it can be done this way. Actually I had a bit more general > >> solution in mind, > >> I feel there should be service to install a file from a store to a > >> given place, and with all the access control available, > >> like acl-s, if supported. And then provide the whole setuid thing as a > >> backwards compatibility layer, somehow like you described. > >> For now I guess creating this record type and implementing the > >> extended setuid functionality would be a good first step. > > > > A service seems like a really good idea to me in that it feels the most > > composable with how Guix currently approaches things. > > I feel like this one needs more "Guix maintainer" overview. I agree, this would be nice. The current > setuid-programs could be kept as legacy behavior that installs an > additional service. Thoughts? I believe it should be kept and install an additional service. I have two reasons for that: backwards compatibility is really important, so we should not break it, and I believe this would not be hard to do. On the other hand it would be nice to have a more integrated backend, and move as many things into the services infrastructure as practical, and I think this is a good candidate for that. Wdyt? Best regards, g_bor -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
linux-module-builder leads to huge store items
Hello Danny & Mathieu, While looking for sources of contention on ci.guix.gnu.org, I found that “linux-libre-module-builder” leads to hge trees in the store; performing deduplication on these trees takes ages, and more generally these big trees look unreasaonble to me. --8<---cut here---start->8--- $ find /gnu/store/s9md49vjambvprpp5ba3aqvhxilw0w7k-linux-libre-module-builder-5.8.8|wc -l 85604 $ du -hs /gnu/store/s9md49vjambvprpp5ba3aqvhxilw0w7k-linux-libre-module-builder-5.8.8 1.1G /gnu/store/s9md49vjambvprpp5ba3aqvhxilw0w7k-linux-libre-module-builder-5.8.8 --8<---cut here---end--->8--- Surely we don’t need that much just to build a kernel module. :-) (gnu build-system linux-module) has this: ;; TODO: Only preserve the minimum, i.e. [Kbuild], Kconfig, ;; scripts, include, ".config". Which files exactly are needed? Can we go ahead and implement this TODO? I understand the need to “cut corners” while trying things out, but I’d argue that this specific corner should have been restored before getting into master. Thanks, Ludo’.
Speeding up archive export
Hello Guix! If you’ve ever used offloading (or ‘guix copy’), you’ve probably noticed that the time to send store items is proportional to the number of store items to send rather than their total size. Namely: guix archive --export coreutils is fast, but: guix archive --export $(guix build -d coreutils) is slow (there are lots of small files). Running ‘perf timechart record guix archive --export …’ confirms the problem: guix-daemon is mostly idle, waiting for all the tiny ‘guix authenticate’ programs it spawns to sign each every store item. Here’s the Gantt diagram (grey = idle, blue = busy): How can we improve on that? Here are several solutions that come to mind: 1. Sign the whole bundle instead of each individual item. That solves the problem, but that would prevent the receiver from storing individual store item signatures in the future (a few years ago Nix added signatures as part of the ‘ValidPathInfo’ table of the store database, and I think that’s something we might want to have too). 2. Sign fewer items: we can do that by signing only store items that are not content-addressed—i.e., resulting from a fixed-output derivation or being a “source” coming from ‘add-to-store’ or similar. That means we wouldn’t have to sign .drv and *-guile-builder, which would make a big difference and is generally advisable. Unfortunately, there’s no easy way to determine whether a store item is content-addressable. Again Nix added “certificate-addressability claims” to ‘ValidPathInfo’, which might help, though it’s not entirely clear. 3. Reimplement ‘guix authenticate’ and a subset of (guix pki) in C++ (!). We could load the keys and the ACL only once, and we wouldn’t have to fork and all, I’m sure it’d be very fast… and very distracting too: I’d rather investigate in the daemon rewrite in Scheme. 4. Spawn ‘guix authenticate’ once and talk to it over a pipe (similar to ‘guix offload’). That might be the easiest short-term solution. Anyway I thought I’d share and invite y’all to brainstorm. :-) All in all, there’s more and more pressure to get our act together regarding the daemon rewrite in Scheme. The difficulty here is to have a series of reasonable milestones rather than all or nothing. Ludo’.
Re: branch master updated: gnu: Add r-loomr.
Hi Ricardo, On Wed, 2020-09-09 at 18:02 +0200, Ricardo Wurmus wrote: > Hi Roel, > > > This is an automated email from the git hooks/post-receive script. > > > > roelj pushed a commit to branch master > > in repository guix. > > > > The following commit(s) were added to refs/heads/master by this > > push: > > new 1f56ec0 gnu: Add r-loomr. > > 1f56ec0 is described below > > > > commit 1f56ec08af704bdc7aa3e143bf5ce351c5306dea > > Author: Roel Janssen > > AuthorDate: Wed Sep 9 16:56:02 2020 +0200 > > > > gnu: Add r-loomr. > > > > * gnu/packages/bioinformatics.scm (r-loomr): New variable. > > This is not free software. See > >https://github.com/mojaveazure/loomR/pull/24 Oh shoot. I'm sorry I didn't see this discussion! > Aside from this, I would like to say two things: > > > gnu/packages/bioinformatics.scm | 26 ++ > > Let’s please not add R packages to (gnu packages bioinformatics) when > it > can be avoided. (In this case there’s no CRAN package, so it’s > fine.) Where would I add a non-CRAN and non-Bioconductor package to? Perhaps this situation won't occur again, and should raise a flag, because I think I've never had this case before. > > +(define-public r-loomr > > + (package > > + (name "r-loomr") > > + (version "0.2.0-beta") > > + (source (origin > > +(method url-fetch) > > +(uri (string-append > > + "https://github.com/mojaveazure/loomR/archive/"; > > + version ".tar.gz")) > > This is not okay as these generated tarballs are not stable. I > haven’t > seen these patches on guix-patches before — maybe I missed them. But > we > have been avoiding these kind of URLs since a long time and had I > seen > the patches on guix-patches I and other would probably have pointed > this > out. > > Can you please revert this ASAP? I see you've reverted it already. Thanks for that! I will default to submitting patches to guix-patches again. I thought it was trivial enough to just push. My mistake. Kind regards, Roel Janssen
Re: branch master updated: gnu: Add r-loomr.
Roel Janssen writes: >> > commit 1f56ec08af704bdc7aa3e143bf5ce351c5306dea >> > Author: Roel Janssen >> > AuthorDate: Wed Sep 9 16:56:02 2020 +0200 >> > >> > gnu: Add r-loomr. >> > >> > * gnu/packages/bioinformatics.scm (r-loomr): New variable. >> >> This is not free software. See >> >>https://github.com/mojaveazure/loomR/pull/24 > > > Oh shoot. I'm sorry I didn't see this discussion! It’s really not obvious. I know because it happened to me too. In 2018 I added r-loomr with commit fab43c6b84635200070c708d4220132be18dd239. Then in 2019 I removed it with commit bc70516bbae8a6388f3ed19008d3e10efd1577a7 after noticing that the author only used GPL in the DESCRIPTION file to stop the CRAN tools from complaining. It’s definitely unusual and very easy to miss. >> Aside from this, I would like to say two things: >> >> > gnu/packages/bioinformatics.scm | 26 ++ >> >> Let’s please not add R packages to (gnu packages bioinformatics) when >> it >> can be avoided. (In this case there’s no CRAN package, so it’s >> fine.) > > Where would I add a non-CRAN and non-Bioconductor package to? Perhaps > this situation won't occur again, and should raise a flag, because I > think I've never had this case before. We don’t have any good place for those packages. It would be good to have a dumping ground for packages like that, and for those that are on CRAN but unusually depend on Bioconductor packages. > I will default to submitting patches to guix-patches again. I thought > it was trivial enough to just push. My mistake. I’d say if it’s on CRAN you can go ahead and push directly (after running “guix lint” to catch some obvious mistakes). Bioconductor packages need a little extra care because they are sometimes playing loose with licenses and included third-party code; but if you feel you’ve checked things carefully then you can also push those directly. For third-party R packages we don’t benefit from even the little bit of quality control that CRAN and Bioconductor impose, so we need to be extra careful. There it helps to send patches to guix-patches and push them after some time. -- Ricardo
Re: branch master updated: gnu: Add r-bisquerna.
Hi Ricardo, On Wed, 2020-09-09 at 18:04 +0200, Ricardo Wurmus wrote: > Hi Roel, > > > This is an automated email from the git hooks/post-receive script. > > > > roelj pushed a commit to branch master > > in repository guix. > > > > The following commit(s) were added to refs/heads/master by this > > push: > > new 0574446 gnu: Add r-bisquerna. > > 0574446 is described below > > > > commit 0574446be82ef54b925441e4283bf754a86918a9 > > Author: Roel Janssen > > AuthorDate: Wed Sep 9 17:02:55 2020 +0200 > > > > gnu: Add r-bisquerna. > > > > * gnu/packages/bioinformatics.scm (r-bisquerna): New variable. > > --- > > gnu/packages/bioinformatics.scm | 25 + > > 1 file changed, 25 insertions(+) > > > > diff --git a/gnu/packages/bioinformatics.scm > > b/gnu/packages/bioinformatics.scm > > index f8792ef..9f2fd86 100644 > > --- a/gnu/packages/bioinformatics.scm > > +++ b/gnu/packages/bioinformatics.scm > > @@ -7923,6 +7923,31 @@ manipulating genomic intervals and variables > > defined along a genome.") > > on Bioconductor or which replace R functions.") > > (license license:artistic2.0))) > > > > +(define-public r-bisquerna > > + (package > > + (name "r-bisquerna") > > + (version "1.0.4") > > + (source (origin > > +(method url-fetch) > > +(uri (cran-uri "BisqueRNA" version)) > > +(sha256 > > + (base32 > > + "01g34n87ml7n3pck77497ddgbv3rr5p4153ac8ninpgjijlm3jw > > 2" > > Why is this in (gnu packages bioinformatics) and not in (gnu packages > cran)? It seemed so "bioinformatics"-specific. But you're right, it's a CRAN package, so that may be a better fit. Shall I move it to CRAN? > > + (synopsis "Decomposition of Bulk Expression with Single-Cell > > Sequencing") > > Please use lowercase where it would be normally used. My mistake. I will take better care of this in the future. Kind regards, Roel Janssen
Re: branch master updated: gnu: Add r-bisquerna.
Roel Janssen writes: >> > +(define-public r-bisquerna >> > + (package >> > + (name "r-bisquerna") >> > + (version "1.0.4") >> > + (source (origin >> > +(method url-fetch) >> > +(uri (cran-uri "BisqueRNA" version)) >> > +(sha256 >> > + (base32 >> > + "01g34n87ml7n3pck77497ddgbv3rr5p4153ac8ninpgjijlm3jw >> > 2" >> >> Why is this in (gnu packages bioinformatics) and not in (gnu packages >> cran)? > > It seemed so "bioinformatics"-specific. But you're right, it's a CRAN > package, so that may be a better fit. Shall I move it to CRAN? If you have time to do that, yes please. Some time ago I started a half-hearted migration of R packages from (gnu packages bioinformatics) to (gnu packages cran) and (gnu packages bioconductor). It’s not supremely important, but I think in the long term we’d like to have CRAN things in (gnu packages cran) and Bioconductor things in (gnu packages bioconductor), because it’s deliciously unsurprising. :) >> > + (synopsis "Decomposition of Bulk Expression with Single-Cell >> > Sequencing") >> >> Please use lowercase where it would be normally used. > > My mistake. I will take better care of this in the future. Thank you! Perhaps we could sprinkle some smarts over the CRAN importer to do this automatically, but with R packages we often have names of methods that should be upper case (like “Bayes*” or “SNPs”), so I have shied away from developing heuristics for that. Thanks for adding more R packages! -- Ricardo
Re: branch master updated: gnu: Add r-bisquerna.
On Thu, 10 Sep 2020 at 13:30, Ricardo Wurmus wrote: > > It seemed so "bioinformatics"-specific. But you're right, it's a CRAN > > package, so that may be a better fit. Shall I move it to CRAN? > > If you have time to do that, yes please. Some time ago I started a > half-hearted migration of R packages from (gnu packages bioinformatics) > to (gnu packages cran) and (gnu packages bioconductor). It’s not > supremely important, but I think in the long term we’d like to have CRAN > things in (gnu packages cran) and Bioconductor things in (gnu packages > bioconductor), because it’s deliciously unsurprising. :) I agree. And it is also on my TODO but the Copyright lines lead to a boring task. :-) Does it make sense to add a subsection to: https://guix.gnu.org/manual/devel/en/guix.html#Packaging-Guidelines about R packages? Cheers, simon
Re: branch master updated: gnu: Add r-loomr.
On Thu, 10 Sep 2020 at 12:40, Ricardo Wurmus wrote: > > Where would I add a non-CRAN and non-Bioconductor package to? Perhaps > > this situation won't occur again, and should raise a flag, because I > > think I've never had this case before. > > We don’t have any good place for those packages. It would be good to > have a dumping ground for packages like that, and for those that are on > CRAN but unusually depend on Bioconductor packages. IMHO, for non-CRAN and non-Bioconductor R packages, they should go to thematic files: bioinformatics.scm or machine-learning.scm or name-it.scm. However, some dependency issues could happen, and e.g., CRAN package could be in bioconductor.scm as r-deconstructsigs -- with a comment. Last, should CRAN packages in statistics.scm go in cran..scm or not? All the best, simon
Re: branch master updated: gnu: Add r-loomr.
zimoun writes: > Last, should CRAN packages in statistics.scm go in cran..scm or not? Yes, I want statistics.scm to no longer have CRAN packages. -- Ricardo
Re: branch master updated: gnu: Add r-bisquerna.
zimoun writes: > On Thu, 10 Sep 2020 at 13:30, Ricardo Wurmus wrote: > >> > It seemed so "bioinformatics"-specific. But you're right, it's a CRAN >> > package, so that may be a better fit. Shall I move it to CRAN? >> >> If you have time to do that, yes please. Some time ago I started a >> half-hearted migration of R packages from (gnu packages bioinformatics) >> to (gnu packages cran) and (gnu packages bioconductor). It’s not >> supremely important, but I think in the long term we’d like to have CRAN >> things in (gnu packages cran) and Bioconductor things in (gnu packages >> bioconductor), because it’s deliciously unsurprising. :) > > I agree. And it is also on my TODO but the Copyright lines lead to a > boring task. :-) It becomes a little easier with “git log --grep=package-name”. > Does it make sense to add a subsection to: > https://guix.gnu.org/manual/devel/en/guix.html#Packaging-Guidelines > about R packages? Perhaps not. I think it may not be necessary because we don’t have that many people contributing R packages to us and the manual already has a lot of information that might be overwhelming. So far we’ve been doing fine without it. It’s a really minor point, in my opinion. -- Ricardo
Re: linux-module-builder leads to huge store items
Hi Ludo, On Thu, 10 Sep 2020 10:09:11 +0200 Ludovic Courtès wrote: > Surely we don’t need that much just to build a kernel module. :-) Since Linux is a monolithic kernel and since C has no modules: Yes, yes we do--in the general case. Linux kernel developers have no interest in supporting out-of-tree modules for free (and no interesting in having the Linux kernel API frozen) so there's no incentive to support a use case where you can compile a Linux kernel module without having the full source of the Linux kernel (that would be just asking for license abuse, too). That would mean that we would have to both design and then support out-of-tree build infrastructure ourselves in Guix. And for what? It's only used when building the module--it will be thrown away afterwards anyway. Or is it not garbage-collected afterwards? That would be a serious bug. > ;; TODO: Only preserve the minimum, i.e. [Kbuild], Kconfig, > ;; scripts, include, ".config". > > Which files exactly are needed? Can we go ahead and implement this TODO? Who knows? Nobody--not even Linux kernel developers. Given the design of C, it's not possible in general to know what is the interface and what is the implementation. I guess for the Linux kernel we could kinda wing it because of the social conventions the Linux kernel enforces where it kinda almost does have a module separation into interface and implementation. > I understand the need to “cut corners” while trying things out, but I’d > argue that this specific corner should have been restored before getting > into master. If you want that, I think you need to argue that with the main Linux kernel maintainers (Greg Kroah-Hartmann etc). I don't think it is practical for us to maintain a weird minimal module-building-only fork of Linux. I'd be glad to be proven wrong, though. Even if we did, there are much worse build-time storage space wastes (*cough* llvm *cough*). That said, I did a quick size comparison and found those big items: 150 MB a2fs24bgghjvlzq5lzr6zki7mqxx8mpi-linux-libre-module-builder-5.8.7/lib/modules/build/drivers/gpu/drm/amd/include/asic_reg 30 MB a2fs24bgghjvlzq5lzr6zki7mqxx8mpi-linux-libre-module-builder-5.8.7/lib/modules/build/drivers/staging I don't think we need these in any potential Linux kernel module--but who knows? Maybe somebody does need those. pgp9bE4buqZmN.pgp Description: OpenPGP digital signature
Re: branch master updated: gnu: Add r-bisquerna.
On Thu, 2020-09-10 at 13:31 +0200, Ricardo Wurmus wrote: > Roel Janssen writes: > > > > > +(define-public r-bisquerna > > > > + (package > > > > + (name "r-bisquerna") > > > > + (version "1.0.4") > > > > + (source (origin > > > > +(method url-fetch) > > > > +(uri (cran-uri "BisqueRNA" version)) > > > > +(sha256 > > > > + (base32 > > > > + "01g34n87ml7n3pck77497ddgbv3rr5p4153ac8ninpgjijl > > > > m3jw > > > > 2" > > > > > > Why is this in (gnu packages bioinformatics) and not in (gnu > > > packages > > > cran)? > > > > It seemed so "bioinformatics"-specific. But you're right, it's a > > CRAN > > package, so that may be a better fit. Shall I move it to CRAN? > > If you have time to do that, yes please. Some time ago I started a > half-hearted migration of R packages from (gnu packages > bioinformatics) > to (gnu packages cran) and (gnu packages bioconductor). It’s not > supremely important, but I think in the long term we’d like to have > CRAN > things in (gnu packages cran) and Bioconductor things in (gnu > packages > bioconductor), because it’s deliciously unsurprising. :) I fully agree that it would be nice to have all packages originating from CRAN in (gnu packages cram) and all things Bioconductor in (gnu packages bioconductor). I moved r-bisquerna and lowercased its synopsis in 66be746dc0c0f4ba3d748ed8d0983b2f9afdace8. Kind regards, Roel Janssen
Re: branch master updated: gnu: Add r-useful.
On Wed, 2020-09-09 at 18:05 +0200, Ricardo Wurmus wrote:
> Hi Roel,
>
> > This is an automated email from the git hooks/post-receive script.
> >
> > roelj pushed a commit to branch master
> > in repository guix.
> >
> > The following commit(s) were added to refs/heads/master by this
> > push:
> > new a9401b4 gnu: Add r-useful.
> > a9401b4 is described below
> >
> > commit a9401b4c948552d6a5a95bbd295e61871f4c6d74
> > Author: Roel Janssen
> > AuthorDate: Wed Sep 9 16:59:42 2020 +0200
> >
> > gnu: Add r-useful.
> >
> > * gnu/packages/cran.scm (r-useful): New variable.
> > ---
> > gnu/packages/cran.scm | 30 ++
> > 1 file changed, 30 insertions(+)
> >
> > diff --git a/gnu/packages/cran.scm b/gnu/packages/cran.scm
> > index 3b13bbd..8f7e379 100644
> > --- a/gnu/packages/cran.scm
> > +++ b/gnu/packages/cran.scm
> > @@ -3724,6 +3724,36 @@ algorithm. The interface of @code{ucminf}
> > is designed for easy interchange
> > with the package @code{optim}.")
> > (license license:gpl2+)))
> >
> > +(define-public r-useful
> > + (package
> > + (name "r-useful")
> > + (version "1.2.6")
> > + (source (origin
> > +(method url-fetch)
> > +(uri (cran-uri "useful" version))
> > +(sha256
> > + (base32
> > + "0n50v1q75k518sq23id14jphwla35q4sasahrnrnllwrachl67v
> > 1"
> > + (properties `((upstream-name . "useful")))
> > + (build-system r-build-system)
> > + (propagated-inputs
> > +`(("r-assertthat" ,r-assertthat)
> > + ("r-dplyr" ,r-dplyr)
> > + ("r-ggplot2" ,r-ggplot2)
> > + ("r-magrittr" ,r-magrittr)
> > + ("r-matrix" ,r-matrix)
> > + ("r-plyr" ,r-plyr)
> > + ("r-purrr" ,r-purrr)
> > + ("r-scales" ,r-scales)))
> > + (home-page "https://github.com/jaredlander/useful";)
> > + (synopsis "A Collection of Handy, Useful Functions")
>
> “guix lint” should have complained about the leading “A”. Please
> also
> use lowercase.
Fixed in 811985a7e0b8e7aad5a3c3818482b06996c94d02.
Kind regards,
Roel Janssen
Re: Setuid programs
Gábor Boskovits writes: > Hello, > > Christopher Lemmer Webber ezt írta (időpont: > 2020. szept. 10., Cs, 0:52): >> >> Christopher Lemmer Webber writes: >> >> > Gábor Boskovits writes: >> > >> >> Hello, >> >> >> >> Christopher Lemmer Webber ezt írta (időpont: >> >> 2020. szept. 9., Sze, 21:00): >> >>> >> >>> Maxim Cournoyer writes: >> >>> >> >>> > Hello Gabor! >> >>> > >> >>> > Gábor Boskovits writes: >> >>> > >> >>> >> Hello guix, >> >>> >> >> >>> >> I would like to propose an extension to how setuid programs are >> >>> >> currently handled. The last time I checked it could only do setuid and >> >>> >> setgid root. Some services, such as postfix need a more fine grained >> >>> >> setuid setup. I would propose a record type, such as: >> >>> >> (setuid >> >>> >> (program setuid-program) >> >>> >> (setuid setuid-setuid) >> >>> >> (setgid setuid-setgid) >> >>> >> (user setuid-user) >> >>> >> (group setuid-group)) >> >>> >> >> >>> >> So that there is more fine grained control. >> >>> >> >> >>> >> I would also propose to move this to the services framework, so that >> >>> >> services could extend this field on demand. >> >>> >> >> >>> >> Wdyt? >> >>> > >> >>> > This sounds great! I also encountered such limitation and tried to >> >>> > fixing it in https://issues.guix.info/41763, with some success (and an >> >>> > unresolved limitation pointed by Chriistopher) but I agree that using a >> >>> > record makes more sense and is more future proof. >> >>> > >> >>> > Maxim >> >>> >> >>> I'm eager to use Postfix on Guix (maybe it's me, but I just can't make >> >>> sense of the weird DSL that opensmtpd uses) so I guess if that's what's >> >>> necessary it already makes it a good idea. >> >>> >> >>> However I don't fully understand the syntax of what you proposed. Let's >> >>> see if I can guess with a fake entry >> >>> >> >>> #~(setuid >> >>>;; The program to run, from the shady package >> >>>(program (string-append #$shady "/bin/scaryfoo") >> >>>;; Would this be a boolean? If so should it be `setuid?` >> >> yes, this should be a bool, studi? looks good to me. >> >>>(setuid setuid-setuid) >> >>>;; Likewise? >> >>>(setgid setuid-setgid) >> >> yes, the same thing applies here. >> >>>;; Presumably the use we want to set this to >> >>>(user setuid-user) >> >> yes, this should just be the uid of the owner >> >>>;; Presumably the group we want to se this to >> >> this should be the gid. >> >>>(group setuid-group)) >> >>> >> >>> ... right? >> >>> >> >>> I guess this could be done in a backwards compatible way; >> >>> %setuid-programs could either evaluate to strings or records, so the >> >>> "simpler" version can remain an option? >> >> Yes, it can be done this way. Actually I had a bit more general >> >> solution in mind, >> >> I feel there should be service to install a file from a store to a >> >> given place, and with all the access control available, >> >> like acl-s, if supported. And then provide the whole setuid thing as a >> >> backwards compatibility layer, somehow like you described. >> >> For now I guess creating this record type and implementing the >> >> extended setuid functionality would be a good first step. >> > >> > A service seems like a really good idea to me in that it feels the most >> > composable with how Guix currently approaches things. >> >> I feel like this one needs more "Guix maintainer" overview. > I agree, this would be nice. > > The current >> setuid-programs could be kept as legacy behavior that installs an >> additional service. Thoughts? > > I believe it should be kept and install an additional service. > > I have two reasons for that: backwards compatibility is really > important, so we should not break it, and I believe this would not be > hard to do. > On the other hand it would be nice to have a more integrated backend, > and move as many things into the services infrastructure as practical, > and I think this is a good candidate for that. Wdyt? > > Best regards, > g_bor That's fine by me. I don't feel like I'm the right one to make the call though!
Re: getting started with the texlive importer
Hi Guix, Ok, I have found a fix. It turns out that the 'svn export' command throws an error if the target directory already exists. Initially I set the 'log' argument of 'download-svn-to-store' to 'current-output-port' to see the error message from svn: svn: E155000: Destination directory exists; please remove the directory or use - -force to overwrite This error is generated because a temporary directory is created by the 'call-with-temporary-directory' procedure (from svn-download.scm). The name of the directory is used as an argument for the 'svn export' command. The fix I have tested is the following: --- a/guix/svn-download.scm +++ b/guix/svn-download.scm @@ -159,10 +159,11 @@ reports to LOG." (parameterize ((current-output-port log)) (build:svn-fetch (svn-reference-url ref) (svn-reference-revision ref) - temp + (string-append temp "/svn") #:user-name (svn-reference-user-name ref) #:password (svn-reference-password ref) (and result -(add-to-store store name #t "sha256" temp)) +(add-to-store store name #t "sha256" + (string-append temp "/svn"))) ;;; svn-download.scm ends here The effect is to add a subdirectory to the temporary directory. This is used as the target to download the files to. It does not exist until created by the 'svn export' command. WDYT? If there are no objections I will push a commit early next week. Best regards, Paul.
Re: linux-module-builder leads to huge store items
Hello, Danny Milosavljevic skribis: > On Thu, 10 Sep 2020 10:09:11 +0200 > Ludovic Courtès wrote: > >> Surely we don’t need that much just to build a kernel module. :-) > > Since Linux is a monolithic kernel and since C has no modules: Yes, yes we > do--in the general case. > > Linux kernel developers have no interest in supporting out-of-tree modules for > free (and no interesting in having the Linux kernel API frozen) so there's no > incentive to support a use case where you can compile a Linux kernel module > without having the full source of the Linux kernel (that would be just asking > for license abuse, too). Understood. > That would mean that we would have to both design and then support out-of-tree > build infrastructure ourselves in Guix. And for what? It's only used when > building the module--it will be thrown away afterwards anyway. > > Or is it not garbage-collected afterwards? That would be a serious bug. It *is* thrown-away afterwards. But until then, it must be deduplicated (upon build completion, reception, etc.), and that’s a lot of work I/O wise given the large number of files. >> ;; TODO: Only preserve the minimum, i.e. [Kbuild], Kconfig, >> ;; scripts, include, ".config". >> >> Which files exactly are needed? Can we go ahead and implement this TODO? > > Who knows? [...] > Even if we did, there are much worse build-time storage space wastes > (*cough* llvm *cough*). But it’s build-time. > That said, I did a quick size comparison and found those big items: > > 150 MB > a2fs24bgghjvlzq5lzr6zki7mqxx8mpi-linux-libre-module-builder-5.8.7/lib/modules/build/drivers/gpu/drm/amd/include/asic_reg > 30 MB > a2fs24bgghjvlzq5lzr6zki7mqxx8mpi-linux-libre-module-builder-5.8.7/lib/modules/build/drivers/staging > > I don't think we need these in any potential Linux kernel module--but who > knows? Maybe somebody does need those. So, I can think of the following ways to address that: 1. Remove for example *.c, assuming the out-of-tree modules we package only care about *.h + build machinery. 2. Don’t add all of the Linux source to the store, or at least not under a new name each time. One way to do that would be to unpack the Linux-libre tree within the build tree of the out-of-tree module. We’d be reducing GC stress at the expense of a (reasonable?) increase in module build time. Thoughts? Ludo’.
Re: getting started with the texlive importer
Nice work! That bug has been around for years I think. Thanks! John
Re: getting started with the texlive importer
Hi Paul, > Ok, I have found a fix. […] > The effect is to add a subdirectory to the temporary directory. This > is used as the target to download the files to. It does not exist > until created by the 'svn export' command. Interesting! I think I added this back then and at some point it used to work as intended. It’s a bit odd that it broke long ago, but I’m very happy you found a way around this error! > WDYT? If there are no objections I will push a commit early next week. Looks good to me. Please push! -- Ricardo
