Re: how to "guix pack" a profile?
Dear, On Fri, 19 Jun 2020 at 11:52, elaexuo...@wilsonb.com wrote: > What Pierre (and others?) initially proposed---what I am > re-proposing---is that we put a blob of Guile into the profiles that > is capable of uniquely and completely generating the profile where it > resides. Others? For example me. With Pierre, we spent some time at Guix Days to propose a new format. > 1. Composable profiles, This is already possible. > 2. Sharing "light" profiles buy sending only the "recipe.scm" instead > of an entire container. I am not sure to get what is a "light" profile but from my understanding what you want here already exist and it is manifest.scm+channel.scm. > 3. guix archive --manifest > 4. guix profile --manifest-from-recipe /recipe.scm > > The last one there is intended to be the tool for "migrate from > imperative to declarative" user profile management, starting from a > given profile. See below. >> What you describe here is exactly what Pierre and other have >> proposed. And the work-to-do is to prototype the format of what you >> called "recipe.scm", which means equivalently in the previous emails >> change the format of /manifest. > > I agree. However, in previous emails I have tried to make a rebuttal > to Ludo's argument than the best we can do is *approximate* a > manifest.scm. > > See https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00098.html: I have the impression that the discussion is going nowhere. Make what you called "recipe.scm" or modify ">>> (Ludo) As far as faithfulness is concerned, we should also keep in mind that we don’t always have all the information needed to reconstruct what’s in a profile. For example, we lack information about the package transformation options that were used (if any), >>> >>> (Pierre) >>> Like `--with-input'? I didn't think of this. Can't we extend the >>> format then to include all transformation options, with future-proof >>> provisions? >> >> (Ludo) >> We couldstore package transformations as manifest entry properties. >> >> However, that’ll be an approximation: the exact implementation of >> ‘--with-input’, for instance, can vary over time. This snippet of quotation shows that it is not "easy" for the general case. And the transformation using "--load-path" has not been evoked. For example: --8<---cut here---start->8--- (define-module (foo) #:use-module (guix packages) #:use-module (guix profiles) ;; imagine it is used #:use-module (gnu packages base)) (define (crazy-transformation pkg) "Could do really complicated things" (package (inherit pkg) (name (string-append "ex-" (package-name pkg) (define bonjour (package (inherit hello) (name "bonjour"))) (define-public crazy-bonjour (crazy-transformation bonjour)) --8<---cut here---end--->8--- then "guix install -L /path/to/foo ex-bonjour". > However, with `time-machine' and a given `guix environment' or `guix > profile' invocation, we are able to deterministically resolve a > /gnu/store/-profile, no? Better yet, this is in a future-proof > way, no? If that is so, then why not canonify this profile recipe in > guile code instead of what is needed now: guile + bash? What am I > missing here? You are missing the difficulty to make it concretely, I guess. :-) > Just to be clear, I would be more than thrilled with a --from-profile > option to `guix pack'. However, I am trying to make a case that "first > class profiles" is both feasible and may pay back more in maintenance > cost than it consumes. Thank you for the ideas. Especially the two ones: 1. create an environment from a profile 2. pack a profile Well, I do not know if they will happen but it should be cool to have. I am going to move on since we already raised all the points, I guess. :-) All the best, simon
Re: how to "guix pack" a profile?
zimoun, Thank you for you time. Apparently, I am indeed missing some important conceptual details. I will come back later when I know more. Cheers and happy Guixing, zimoun wrote: > Dear, > > On Fri, 19 Jun 2020 at 11:52, elaexuo...@wilsonb.com wrote: > > > What Pierre (and others?) initially proposed---what I am > > re-proposing---is that we put a blob of Guile into the profiles that > > is capable of uniquely and completely generating the profile where it > > resides. > > Others? For example me. With Pierre, we spent some time at Guix Days > to propose a new format. > > > 1. Composable profiles, > > This is already possible. > > > 2. Sharing "light" profiles buy sending only the "recipe.scm" instead > > of an entire container. > > I am not sure to get what is a "light" profile but from my understanding > what you want here already exist and it is manifest.scm+channel.scm. > > > 3. guix archive --manifest > > 4. guix profile --manifest-from-recipe /recipe.scm > > > > The last one there is intended to be the tool for "migrate from > > imperative to declarative" user profile management, starting from a > > given profile. > > See below. > > >> What you describe here is exactly what Pierre and other have > >> proposed. And the work-to-do is to prototype the format of what you > >> called "recipe.scm", which means equivalently in the previous emails > >> change the format of /manifest. > > > > I agree. However, in previous emails I have tried to make a rebuttal > > to Ludo's argument than the best we can do is *approximate* a > > manifest.scm. > > > > See https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00098.html: > > I have the impression that the discussion is going nowhere. > > Make what you called "recipe.scm" or modify " become an acceptable "--manifest" is doable. Note that the idea is not > new either. As I said, all the technical material is here. But Ludo > and others (me) are not convinced that it will pay off because the > general case is hard. Well, to be concrete, there are 2 possible next > actions: > > a) prototype the new format and implement it > b) make an approximation exposed with "--export" > > Frankly, I doubt that a) happens because no one will do the tough work. > Therefore, b) is pragmatic. > > > (Ludo) > As far as faithfulness is concerned, we should also keep in mind > that we don’t always have all the information needed to reconstruct > what’s in a profile. For example, we lack information about the > package transformation options that were used (if any), > >>> > >>> (Pierre) > >>> Like `--with-input'? I didn't think of this. Can't we extend the > >>> format then to include all transformation options, with future-proof > >>> provisions? > >> > >> (Ludo) > >> We couldstore package transformations as manifest entry properties. > >> > >> However, that’ll be an approximation: the exact implementation of > >> ‘--with-input’, for instance, can vary over time. > > This snippet of quotation shows that it is not "easy" for the general > case. And the transformation using "--load-path" has not been evoked. > For example: > > --8<---cut here---start->8--- > (define-module (foo) > #:use-module (guix packages) > #:use-module (guix profiles) ;; imagine it is used > #:use-module (gnu packages base)) > > (define (crazy-transformation pkg) > "Could do really complicated things" > (package > (inherit pkg) > (name (string-append "ex-" (package-name pkg) > > (define bonjour > (package > (inherit hello) > (name "bonjour"))) > > (define-public crazy-bonjour > (crazy-transformation bonjour)) > --8<---cut here---end--->8--- > > then "guix install -L /path/to/foo ex-bonjour". > > > > However, with `time-machine' and a given `guix environment' or `guix > > profile' invocation, we are able to deterministically resolve a > > /gnu/store/-profile, no? Better yet, this is in a future-proof > > way, no? If that is so, then why not canonify this profile recipe in > > guile code instead of what is needed now: guile + bash? What am I > > missing here? > > You are missing the difficulty to make it concretely, I guess. :-) > > > > Just to be clear, I would be more than thrilled with a --from-profile > > option to `guix pack'. However, I am trying to make a case that "first > > class profiles" is both feasible and may pay back more in maintenance > > cost than it consumes. > > Thank you for the ideas. Especially the two ones: > > 1. create an environment from a profile > 2. pack a profile > > Well, I do not know if they will happen but it should be cool to have. > > > I am going to move on since we already raised all the points, I guess. :-) > > > All the best, > simon signature.asc Description: PGP signature
Re: how to "guix pack" a profile?
On Fri, 19 Jun 2020 at 11:52, elaexuo...@wilsonb.com wrote: > You emphasize that declarative package management with "manifest.scm" is the > way to go. I agree but wanted to point out that > > $ guix package -m manifest.scm > > produces a different /gnu/store/-profile, depending on when it's run (or > more precisely, depending on which channel commits guix resolves for the > invocation). Yes, but AFAIU the correct is: guix describe -f channels > channel.scm guix package -m manifest.scm then later or elsewhere, reproduce with: guix time-machine -C channel.scm -- package -m manifest.scm > You know that, of course, but the point I try to make is that "manifest.scm" > and "channels.scm" are *not enough* to uniquely determine a specific > /gnu/store/-profile. We need to separate out the concepts of > "declarative > profile management" and "deterministic profile regeneration." Do you have examples? I am not sure we are talking about the same channels.scm file. I guess, you have in mind ~/.config/guix/channels.scm but it is not the one of interest for reproducing. You need the real one, i.e., "guix describe -f channels". AFAIU, manifest.scm+$(guix describe -f channel) is enough to have "deterministic profile (re)generation". If not, it means there is a "bug" in Inferiors or I miss something. All the best, simon
Re: “Reproducible research articles, from source code to PDF”
Hi, Konrad Hinsen skribis: > Ludovic Courtès writes: > >>> Maybe we could organize a Virtual Hackathon? Over 1 day? Or 2 days? >>> The power of collective motivation. :-) >> >> Sounds like a good idea! Perhaps a one-day hackathon to begin with? >> Early July maybe? > > Sounds fine. I am not much of a hackathon expert, so I don't propose > myself for organizing this, but I can make a preselection of suitable > submissions to the ReScience challenge (no proprietary software etc.) > with comments about the specific challenges. I’d happily defer to Simon; Simon, would you be able to organize this? I guess we don’t need much actually: a date, an IRC channel, and perhaps a web page on hpc.guix.info announcing the event so others can join. Ludo’.
Re: “Reproducible research articles, from source code to PDF”
On Fri, 19 Jun 2020 at 14:04, Ludovic Courtès wrote: > I’d happily defer to Simon; Simon, would you be able to organize this? Yesterday evening, I have sent an email to guix-hpc with the subject: "Let sync Hackathon reproducible and past" for this purpose. :-) Is this email lost? Or somehow blocked? Let me know? Well, I do not know if I would be able to organize but I can do my best. :-) > I guess we don’t need much actually: a date, an IRC channel, and > perhaps a web page on hpc.guix.info announcing the event so others can > join. The email mentioned above asks exactly that: first pick a date. And for the sake of archive, I started another thread. Cheers, simon
Re: how to "guix pack" a profile?
> I am not sure we are talking about the same channels.scm file. I guess, > you have in mind ~/.config/guix/channels.scm but it is not the one of > interest for reproducing. You need the real one, i.e., "guix describe > -f channels". > > AFAIU, manifest.scm+$(guix describe -f channel) is enough to have > "deterministic profile (re)generation". If not, it means there is a > "bug" in Inferiors or I miss something. Bingo! This is exactly what I was missing. Thank you for sifting this out. Given the stated "goal of ... [allowing] users to move towards declarative 'manifest.scm' style..." I completely mis-interpreted the sense in which you were using "channels.scm". signature.asc Description: PGP signature
Re: how to "guix pack" a profile?
> > 1. Composable profiles, > > This is already possible. Would you kindly point me to the documentation? I am failing to find it. By "composable profiles" what I have in mind is the sum of two existing profiles and extending them as necessary $ guix environment --with-profile saved-profiles/profile-A \ --with-profile saved-profiles/profile-B \ > This snippet of quotation shows that it is not "easy" for the general > case. And the transformation using "--load-path" has not been evoked. > For example: > > --8<---cut here---start->8--- > (define-module (foo) > #:use-module (guix packages) > #:use-module (guix profiles) ;; imagine it is used > #:use-module (gnu packages base)) > > (define (crazy-transformation pkg) > "Could do really complicated things" > (package > (inherit pkg) > (name (string-append "ex-" (package-name pkg) > > (define bonjour > (package > (inherit hello) > (name "bonjour"))) > > (define-public crazy-bonjour > (crazy-transformation bonjour)) > --8<---cut here---end--->8--- > > then "guix install -L /path/to/foo ex-bonjour". Thank you for the concrete example. I guess it wasn't clear in my previous emails, but I proposed *simply copying /path/to/foo* into the generated profile and letting "manifest.scm" refer to these copies. Is this obviously broken. > Thank you for the ideas. Especially the two ones: > > 1. create an environment from a profile > 2. pack a profile > > Well, I do not know if they will happen but it should be cool to have. I agree. If I'm to make any points, I should just submit some concrete patches. Again, thank you for your time and patience. Cheers, signature.asc Description: PGP signature
Re: “Reproducible research articles, from source code to PDF”
zimoun skribis: > On Fri, 19 Jun 2020 at 14:04, Ludovic Courtès > wrote: > >> I’d happily defer to Simon; Simon, would you be able to organize this? > > Yesterday evening, I have sent an email to guix-hpc with the subject: > "Let sync Hackathon reproducible and past" for this purpose. :-) > Is this email lost? Or somehow blocked? Let me know? Oh great, let me check mail… Ludo’.
Re: how to "guix pack" a profile?
On Fri, 19 Jun 2020 at 14:34, wrote: > > > 1. Composable profiles, > > > > This is already possible. > > Would you kindly point me to the documentation? I am failing to find it. guix install hello -p foo guix install emacs -p bar eval $(guix package -p foo -p bar --search-paths=exact) So it composes. However maybe not what you had in mind. ;-) > By "composable profiles" what I have in mind is the sum of two existing > profiles and extending them as necessary > > $ guix environment --with-profile saved-profiles/profile-A \ >--with-profile saved-profiles/profile-B \ > Yes, because "guix environment" cannot support "profile". As said, IMHO you raised 2 interesting use cases: 1. create an environment based on a profile 2. pack an existing profile Obviously "a profile" means the composition of profiles if any. > I agree. If I'm to make any points, I should just submit some concrete > patches. Patches are always welcome. :-) Cheers, simon ps: Well, maybe we are falling in the "take it to private email" thread pattern. ;-) https://joeyh.name/blog/entry/thread_patterns/
Re: Release Guix 1.1.1?
On Thu, Jun 18, 2020 at 11:31:07PM +0200, zimoun wrote: > - What is the status of "alsa-lib cannot find its plugin"? The patch works (last time I tested a couple weeks ago) but I would really like a review of the C-language parts of the patch. signature.asc Description: PGP signature
Re: bug#35728: Tor & IceCat's TorButton shows it's connected but doesn't route the traffic
Mark H Weaver dixit (2020-06-18, 03:45): > Hello again. > > In my previous message, I asked: > > Which version of Debian did you test with, and how did you > > install the Firefox that you used for testing this? > > Also, what version of Firefox did you test with? Mark, That was more than a year ago, I cannot recall. I'm also not using Debian anymore so I cannot check it. Best regards, Marcin
Re: K of N trust in substitutes (related to reproducible builds)
Hi, Christopher Baines skribis: > Ludovic Courtès writes: > >>> 3: http://theworld.com/~cme/spki.txt >>> >>> Using the above ACL, you'd trust a substitute for a path with a specific >>> hash if you can find 2 narinfos for that path and hash if they're signed >>> with keys in that entry. Multiple entries would still be supported, and >>> you wouldn't need to specify the k-of-n bit if you don't want to. >>> >>> I'm not quite sure how expressive this is, or if there are some policies >>> that would be good to support that either can't be expressed, or can't >>> be expressed easily. There's probably other approaches, and how to >>> support trusting substitutes is an important part to consider. >> >> I would be tempted to not bake it into /etc/guix/acl. You would still >> authorize all the servers, but instead of choosing a policy that accepts >> anything signed by one of them, as is currently the case, you would >> choose a policy that only accepts something signed by two of them. >> >> The policy would be implemented in (guix scripts substitute). I haven’t >> put much thought into it but it could be something akin to >> ‘lookup-narinfos/diverse’, roughly. >> >> Thoughts? > > I think that could work, do you have any suggestions on how that "two" > would be configured? I guess it could be a boolean on/off, but it would > be probably more extensible to just allow providing a minimum number of > substitiute servers to agree. There should be a procedure that takes a list of narinfos signed with an authorized key and returns a Boolean. Then there can be a higher-order procedure returning a predicate, like: (make-ratio-predicate k n) The user-chosen predicate could live in /etc/guix/substitute-policy.scm or similar. Thanks, Ludo’.
Re: how to "guix pack" a profile?
Hi, zimoun skribis: > Ludo, WDYT about "guix pack -p profile" to generate a (relocatable) > tarball or Docker image? I mean if it is not already possible. :-) That could work, but honestly I’d rather encourage -m. I’m not convinced there’s a need for what you suggest here. Ludo’.
Re: how to "guix pack" a profile?
Hi,
elaexuo...@wilsonb.com skribis:
> What Pierre (and others?) initially proposed---what I am re-proposing---is
> that
> we put a blob of Guile into the profiles that is capable of uniquely and
> completely generating the profile where it resides.
What you propose is what ‘guix system reconfigure’ does: it produces
/run/current-system/{channels,configuration}.scm and you can reuse them
right away.
The different with ‘guix package’ is that ‘guix system’ supports nothing
but a declarative mode, so it’s easy to do the above.
Conversely, profiles can be managed “imperatively”. Thus, in the
general case, it’s not possible to write a ‘manifest.scm’ file
corresponding to a profile.
I hope this clarifies the situation.
Ludo’.
Re: generate commit messages for package updates
Hi, Ricardo Wurmus skribis: > Ludovic Courtès writes: > >> Pierre Neidhardt skribis: >> >>> Is it worth including in guix/etc? >> >> I think it’d be nice! > > I fixed a bug and added etc/committer.scm.in. Yay! Consider adding a line in “Contributing” to mention its existence. Thank you, Ludo’.
Re: Latest download from website
Hi, Mathieu Othacehe skribis: >> That looks nice to me! I think it should prominently say that these are >> “development snapshots” (probably these two words must appear) though, >> and perhaps contain a link to /download for those looking for releases. >> >> Other than that, I’d say go for it! > > I took your remark into account and pushed. However, I missed > something. As the website is built as a derivation, there's no network > connection and the "latest-builds" request fails. > > ERROR: In procedure getaddrinfo: > In procedure getaddrinfo: Servname not supported for ai_socktype > building pages in '/tmp/gnu.org/software/guix'... > Backtrace: >2 (primitive-load "/gnu/store/k2r4jxc4jww15f05n3kndxrk0a4?") > In ice-9/eval.scm: > 619:8 1 (_ #f) > In guix/build/utils.scm: > 654:6 0 (invoke _ . _) > > Do you see a work-around? I missed something. Can’t we have a static page that refers to ci.guix.gnu.org/…/latest, and Cuirass returns a redirect from /latest to the actual URL? Thanks, Ludo’.
Re: (propagated) 'inputs' depends on 'outputs'?
Hi,
zimoun skribis:
> I am not sure to get the point. From my understanding, it could be
> possible to add information to native-inputs, inputs and
> propagated-inputs, e.g.,
>
> ;; For 'git-svn'.
> ("subversion" ,subversion "svn")
> ("perl-term-readkey" ,perl-term-readkey "svn")
>
> or whatever other mean. Then it becomes possible to only build e.g.,
> git:svn and/or propagate specific inputs depending on the outputs.
The ‘TODO’ file, which is really a museum, has this:
** extend ‘propagated-build-inputs’ with support for multiple outputs
#+BEGIN_SRC scheme
(outputs '("out" "include"))
(propagated-build-inputs
`"i1" ,p1 "o1")
("i2" ,p2))
=> "include")
("i3" ,p3)))
#+END_SRC
Is this what you have in mind?
Ludo’.
Re: Change the '--with-source' flag to use the syntax `--with-source=PACKAGE=SOURCE`
Hi, pkill9 skribis: > I propose changing the `--with-source` flag to use the syntax of > similar `--with-...` flags such as `--with-commit`, e.g. > `--with-source=PACKAGE=SOURCE`, because currently you need to > change a file to match the form "package-version.extension`, and it > searches the package graph to find the package to replace the input > with. It's annoying having to download a source file and change it's > filename just to have it work with this flag. You can use ‘--with-source=PACKAGE=SOURCE’, too: https://guix.gnu.org/manual/en/html_node/Package-Transformation-Options.html Ludo’.
Re: backtrace when building os
Hi, Jan Synacek skribis: > $ cat guix-os.scm > (use-modules (gnu bootloader) >(gnu bootloader grub) >(gnu system file-systems)) > > (operating-system > (host-name "jsynacek-guix-os") > (timezone "Europe/Prague") > (locale "en_US.utf8") > (bootloader > (bootloader-configuration > (bootloader grub-efi-bootloader) > (target "/dev/sdx"))) > (file-systems > (list (file-system (mount-point "/home") >(device "/dev/sda33") >(type "ext4") This OS lacks a root file system (which is no excuse for throwing a backtrace, though!). Ludo’.
Re: (propagated) 'inputs' depends on 'outputs'?
Hi Ludo,
On Fri, 19 Jun 2020 at 22:47, Ludovic Courtès wrote:
> zimoun skribis:
>> ;; For 'git-svn'.
>> ("subversion" ,subversion "svn")
>> ("perl-term-readkey" ,perl-term-readkey "svn")
> The ‘TODO’ file, which is really a museum, has this:
>
> ** extend ‘propagated-build-inputs’ with support for multiple outputs
>
> #+BEGIN_SRC scheme
> (outputs '("out" "include"))
> (propagated-build-inputs
> `"i1" ,p1 "o1")
> ("i2" ,p2))
>=> "include")
> ("i3" ,p3)))
> #+END_SRC
>
>
> Is this what you have in mind?
Yes. That's why it is important to go to museum. ;-)
But if the idea is old and has not happened yet, maybe it is not
worth... For Git, for sure! :-)
All the best,
simon
Re: Change the '--with-source' flag to use the syntax `--with-source=PACKAGE=SOURCE`
> You can use ‘--with-source=PACKAGE=SOURCE’, too: > > https://guix.gnu.org/manual/en/html_node/Package-Transformation-Options.html Ah great, thanks!
Re: Jami bug source investigation #4
Hello, it turns out there is a directory in libringclient package - include/libringclient/web-chatview and it contains the missing files, including the "web.gresource.xml" make and configure complain about. I need to copy the files from include/libringclient/web-chatview of libringclient package to source/web/ of jami package. How do I do this? I tried using modify-phases and just copying the files, but it fails in the same manner, while in the build directory obtained using "--keep-failed", there are only links to the files. Jan Wielkiewicz
Re: [OUTREACHY]: Integration of desktop environments into GNU Guix
@Danny Please find the attached patches. @Others Please find the following git log. commit a412459054b7ad00738dc66cb2035638f9c11b3c Author: Raghav Gururajan Date: Fri Jun 19 19:11:28 2020 -0400 gnu: gst-libav: Update package definition. * gnu/packages/gstreamer.scm (gst-libav): Update package definition. [arguments]<#:phases>['patch-docbook-xml]: New phase. [native-inputs]: Add docbook-xml, perl and ruby. [inputs]: Remove gst-plugins-base, orc and zlib. [propagated-inputs]: Add gstreamer and gst-plugins-base. [synopsis]: Modify. [description]: Modify. [license]: Change from gpl2+ to lgpl2.0+. commit 0109580032805d61700513aa5aee0891fed96b3c Author: Raghav Gururajan Date: Fri Jun 19 18:53:51 2020 -0400 gnu: gst-plugins-ugly: Update package definition. * gnu/packages/gstreamer.scm (gst-plugins-ugly): Update package definition. [arguments]<#:glib-or-gtk?>: New argument. <#:phases>['patch-docbook-xml]: New phase. ['pre-check]: New phase. [native-inputs]: Add docbook-xml, gettext-minimal, gsettings-desktop-schemas, perl and xorg-server-for-tests. [inputs]: Add glib, glib-networking and opencore-amr. Remove gst-plugins-base. [propagated-inputs]: Add gstreamer and gst-plugins-base. [synopsis]: Modify. [description]: Modify. commit 8d47e7bc65fa241e761e8a723a147f9c097f66d2 Author: Raghav Gururajan Date: Fri Jun 19 18:48:19 2020 -0400 gnu: gst-plugins-bad: Update package definition. * gnu/packages/gstreamer.scm (gst-plugins-base): Update package definition. [outputs]: New output 'doc'. [arguments]<#:glib-or-gtk?>: New argument. <#:phases>['patch-docbook-xml]: New phase. ['pre-check]: New phase. ['move-doc]: New phase. [native-inputs]: Add docbook-xml, gettext-minimal, gsettings-desktop-schemas, perl, libxml2 and xorg-server-for-tests. [inputs]: Add bzip2, cairo, ccextractor, chromaprint, directfb, faac, flite, glib, glib-networking, glu, gsm, iqa, lcms, libaom, libbs2b, libdc1394, libdca, libde265, libdrm, libexif, libfdk, libgme, libmfx, libmms, libmpcdec, libnice, libofa, libopenmpt, libtiff, libva, libx11, libxcb, libxext, libxshm, lilv, lv2, mjpegtools, nettle, opencv, openh264, openni2, pango, rtmpdump, sbc, sctp, spandsp, srt, svt-hevc, transcode, v4l-utils, vo-aacenc, vo-amrwbenc, vulkan-headers, vulkan-loader, webrtc-audio-processing, wildmidi, wpebackend-fdo, zbar and zxing-cpp. [propagated-inputs]: Add gstreamer and gst-plugins-base. [synopsis]: Modify. [description]: Modify. commit 5970d09c8db16c565ccdf9e3964829affdab2f6c Author: Raghav Gururajan Date: Thu Jun 18 21:05:20 2020 -0400 gnu: Add openni2. * gnu/packages/gstreamer.scm (openni2): New variable. commit f16e64e5afee6d70814cbf9b5730cb1b00f7589f Author: Raghav Gururajan Date: Thu Jun 18 20:38:35 2020 -0400 gnu: Add libnice. * gnu/packages/networking.scm (libnice): New variable. commit 3e032569d0dfe0b2f5b184b65f5534532abda5f3 Author: Raghav Gururajan Date: Thu Jun 18 12:33:53 2020 -0400 gnu: Add rtmpdump. * gnu/packages/networking.scm (rtmpdump): New variable. commit 4fdfc0999a8f16d563a6651875859973af798b1c Author: Raghav Gururajan Date: Thu Jun 18 12:29:16 2020 -0400 gnu: Add iqa. * gnu/packages/image.scm (iqa): New variable. commit bf481717c8a0b306c532eb5d3cc170c1581f4324 Author: Raghav Gururajan Date: Thu Jun 18 10:04:15 2020 -0400 gnu: Add zxing-cpp. * gnu/packages/aidc.scm (zxing-cpp): New variable. commit b34d5c89db9df4b63906e6b716610de4d423efe1 Author: Raghav Gururajan Date: Thu Jun 18 09:25:50 2020 -0400 gnu: Add wildmidi. * gnu/packages/audio.scm (wildmidi): New variable. commit 6dc93ef31c2ecca6618638a1d92c790c3bf9 Author: Raghav Gururajan Date: Thu Jun 18 06:55:01 2020 -0400 gnu: Add webrtc-audio-processing. * gnu/packages/audio.scm (webrtc-audio-processing): New variable. commit 3f49b0393cb26eb88fe9efc0f25853a3a62de36b Author: Raghav Gururajan Date: Thu Jun 18 06:14:20 2020 -0400 gnu: Add vo-aacenc. * gnu/packages/audio.scm (vo-aacenc): New variable. commit 9244d35ef12b4bd975f2bcd3a5e485aaa8bf7d20 Author: Raghav Gururajan Date: Wed Jun 17 16:50:58 2020 -0400 gnu: Add transcode. * gnu/packages/video.scm (transcode): New variable. commit fca9377762504f4fb70bc1427335dafbed4b0fe5 Author: Raghav Gururajan Date: Wed Jun 17 15:07:02 2020 -0400 gnu: Add tinyalsa. * gnu/packages/audio.scm (tinyalsa): New variable. commit 01e1f8eeb2688c960dfa861945bd4691e598f8b0 Author: Raghav Gururajan Date: Wed Jun 17 13:22:49 2020 -0400 gnu: Add svt-hevc. * gnu/packages/video.scm (svt-hevc): New variable. commit 3ba833d7d6bbed44cfb44429da56f84f6ba36cdf Author: Raghav Gururajan Date: Wed Jun 17 13:00:23 2020 -0400 gnu: Add srt. * gnu/packages/networking.scm (srt): New variable. commit a24c295775edcf71916f7c6d987c74abcf
Policy to remove broken packages
Dear, After Guix Days 2019, the idea of having an informal policy to remove broken packages had emerged. Quoting the initial Björn's message [1]: > If a package is broken for more than 6 months, we should just > remove it from Guix. Prior to removing, we should announce on > the dev mailing list, maybe someone will care about it > then. If there is no response within 2 weeks, we really remove > it. And we all agreed. :-) How to make it happen? Where is the correct place to mark list them: Data Service or Cuirass? 1: https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00019.html All the best, simon
Re: how to "guix pack" a profile?
Ludovic Courtès wrote: > Hi, > > zimoun skribis: > > > Ludo, WDYT about "guix pack -p profile" to generate a (relocatable) > > tarball or Docker image? I mean if it is not already possible. :-) > > That could work, but honestly I’d rather encourage -m. I’m not > convinced there’s a need for what you suggest here. > > Ludo’. The original proposal for this was to enable packing a development environment, as opposed to an --ad-hoc collection of packages. Am I simply missing how to do this? signature.asc Description: PGP signature
Re: how to "guix pack" a profile?
At this point, I am probably firmly in kOOk territory. :p For now I will stay silent on the issue until I have some concrete code to share. Thank you for sincerely engaging with me. Cheers, zimoun wrote: > On Fri, 19 Jun 2020 at 14:34, wrote: > > > > 1. Composable profiles, > > > > > > This is already possible. > > > > Would you kindly point me to the documentation? I am failing to find it. > > guix install hello -p foo > guix install emacs -p bar > eval $(guix package -p foo -p bar --search-paths=exact) > > So it composes. However maybe not what you had in mind. ;-) > > > By "composable profiles" what I have in mind is the sum of two existing > > profiles and extending them as necessary > > > > $ guix environment --with-profile saved-profiles/profile-A \ > >--with-profile saved-profiles/profile-B \ > > > > Yes, because "guix environment" cannot support "profile". As said, > IMHO you raised 2 interesting use cases: > > 1. create an environment based on a profile > 2. pack an existing profile > > Obviously "a profile" means the composition of profiles if any. > > > > I agree. If I'm to make any points, I should just submit some concrete > > patches. > > Patches are always welcome. :-) > > > Cheers, > simon > > ps: > Well, maybe we are falling in the "take it to private email" thread pattern. > ;-) > https://joeyh.name/blog/entry/thread_patterns/
