Re: Questions regarding substitutes with debug output
Olivier Dion writes: > On Thu, 28 Apr 2022, Ricardo Wurmus wrote: >> Olivier Dion writes: >> >>> In my case, I prefer to avoid using package object directly. As >>> mentioned in GWL' manual, the version of Guix running GWL and the >>> version of Guix used by GWL (the inferior) might not be the same. Thus, >>> it is not okay for reproducibility in the long term. In my case, I use >>> `guix time-machine --channels` as the inferior. >> >> The process itself could specify channels to use for its environment. >> Then it would be self-contained and reproducible without having to rely >> on time-machine. > > Is this already supported in GWL? I'm not sure if I understand how you > would do this. How would it be different from using time-machine? It is not yet supported in GWL, but it would only be a small change. The GWL has support for inferiors but currently only uses the “invoking” Guix for packages. We could use a different set of channels per process definition. Each process runs in its own environment; it doesn’t have to be all done with the same version of Guix. Whether or not to support this is merely a question of how easily workflows and processes can be reused or integrated in other workflows. -- Ricardo
Re: Screen sharing ungoogled-chromium
Hi phodina this sounds like an upstream bug, or do you think it depends on Guix packaging? phodina via writes: > Hi, > > I'm attempting to share my screen in the chromium browser (100.0.4896.127-1). > > I've enabled the #enable-webrtc-pipewire-capturer flag and I also have > xdg-desktop-portal install on my Guix System. > > However, when I click in Teams do you mean Microsoft Teams? I never used that service, sorry I cannot help here. [...] > Does somebody use the screen sharing feature? I regurarly use the screen sharing feature in Jitsi and it works out of the box (some previous ungoogled-chromium had issues with video on Jisti, depending on servers) HTH! Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: Questions regarding substitutes with debug output
On Thu, 28 Apr 2022, Ricardo Wurmus wrote: > Olivier Dion writes: > >> In my case, I prefer to avoid using package object directly. As >> mentioned in GWL' manual, the version of Guix running GWL and the >> version of Guix used by GWL (the inferior) might not be the same. Thus, >> it is not okay for reproducibility in the long term. In my case, I use >> `guix time-machine --channels` as the inferior. > > The process itself could specify channels to use for its environment. > Then it would be self-contained and reproducible without having to rely > on time-machine. Is this already supported in GWL? I'm not sure if I understand how you would do this. How would it be different from using time-machine? -- Olivier Dion oldiob.dev
Re: Questions regarding substitutes with debug output
On Thu, 28 Apr 2022, Olivier Dion wrote: > setfff Oops :-O. Tell me you're using emacs without telling me you're using emacs. -- Olivier Dion oldiob.dev
Re: Questions regarding substitutes with debug output
On Thu, 28 Apr 2022, zimoun wrote:
> Hi,
>
> On Fri, 22 Apr 2022 at 10:29, Olivier Dion via wrote:
>> On Fri, 22 Apr 2022, Maxim Cournoyer wrote:
>
>>> Channels can only extend, not override the default Guix channel (the
>>> world would be a bit of a mess if it did). So the easiest path is to
>>> use a different name; alternatively for graph rewriting you could use
>>> the various APIs to effect package transformations.
>>
>> Would be nice to have some way to specify channel in a package
>> specification. I don't think that it would break things if we
>> considerer channels as namespaces, i.e. different graph. A
>> specification like:
>>
>> {channel}package@version:output
>>
>> would be useful. For now I will just rename them to "my/package".
>
> What do you mean by «different graph»? From my understanding, the
> additions of channels makes just the graph bigger: extending the initial
> (upstream) graph with more nodes (channel). :-)
Right it's not a new graph per say since you're not introducing the full
dependencies themself. You're only pulling more nodes into the graph.
I guess the correct term would be a "view" of the graph.
My point being it would be cool if we can specify a package with a
preference if two packages have the same name. It could be the channel
name, but it could also be some metadata provided by Guix. So really,
one could build a specific query (specification) until only a single
package is left from the setfff of matches.
Could be something like:
"guile@3.0.8:debug;channel=my-channel;some-metadata=foo"
I don't know, I'm making syntax up. But I think it would be useful in
cases outside of mine. I'm thinking about root filesystems for embedded
systems where you might want to use a variant of some package.
> IIUC, the question is how to refer to these nodes, and from my
> understanding, we use basically two ways:
>
> 1. by symbol; and thanks to Guile modules, this way provides
> namespaces, somehow.
>
> 2. by metadata (name, version, output); and here I am not convinced it
> is doable to have a namespace but maybe mimic it.
>
> Therefore, since your question is rooted from GWL:
>
> I need to specify the package programmatically as a string in
> Guile. More specifically in the process packages field of Guix
> Workflow Language.
>
> maybe GWL could also accept a symbol instead of a name string. Well, I
> have not used GWL since many months and I do not remember but I think it
> is doable. Ricardo?
In my case, I prefer to avoid using package object directly. As
mentioned in GWL' manual, the version of Guix running GWL and the
version of Guix used by GWL (the inferior) might not be the same. Thus,
it is not okay for reproducibility in the long term. In my case, I use
`guix time-machine --channels` as the inferior.
> Last, back to the feature you would like – be able to write:
>
> (specifications->manifest (list "foo"))
>
> and select "foo" from your channel instead from upstream, right? Or a
> way to specify the channel using the symbol from the name field in
> , right?
Correct. In fact as I mentioned above, I think having a way to select a
package variant -- e.g. if you've introduced an existing package in your
channel -- is a more generic way of describing it. Selection of channel
being only a type of metadata that can be used for selection of the
variant. More metadata could be added in the future as well.
> Aside the syntax of the string – why not the one your are proposing –
> and so adapt ’package-name->name+version’ (or similar), the function
> ’find-best-packages-by-name’ requires some improvements.
>
> What I am missing is the mapping from channel name to package. Well,
> Guix does not track this information at pull time. And I miss how to
> implement such mapping.
I could not say. I don't know much about the internal of Guix :-/.
> Therefore, assuming this mapping, the package cache
> (%package-cache-file) could be updated to also track such map. Such
> feature would also simplify when searching; especially for variants
> (same as upstream but other arguments).
Yes that would be the idea!
Regards,
old
--
Olivier Dion
oldiob.dev
Re: Questions regarding substitutes with debug output
Olivier Dion writes: >> Therefore, since your question is rooted from GWL: >> >> I need to specify the package programmatically as a string in >> Guile. More specifically in the process packages field of Guix >> Workflow Language. >> >> maybe GWL could also accept a symbol instead of a name string. Well, I >> have not used GWL since many months and I do not remember but I think it >> is doable. Ricardo? > > In my case, I prefer to avoid using package object directly. As > mentioned in GWL' manual, the version of Guix running GWL and the > version of Guix used by GWL (the inferior) might not be the same. Thus, > it is not okay for reproducibility in the long term. In my case, I use > `guix time-machine --channels` as the inferior. The process itself could specify channels to use for its environment. Then it would be self-contained and reproducible without having to rely on time-machine. -- Ricardo
Re: guix pull; guix package -u; sudo guix system reconfigure /etc/config.scm
> When I did it two days ago it took 6 hours. I couldn't swich off my > laptop. You can switch your laptop. Whatever was fully compiled or downloaded before stopping the upgrade will be kept, and running it again will pick it up from there.
Re: How to prevent incomplete build results from being garbage collected?
Hi, On Sat, 16 Apr 2022 at 13:32, James Thomas wrote: > Mykola Nikishov wrote: >> #+begin_example >> guix build >> guix gc >> guix build >> #+end_example [...] > guix shell -D -r In addition, you could use “guix gc -F 10G” or whatever space you would like to reclaim. Because “guix gc” delete all dead items whereas the option ’-F’ (or ’-C’) tries to determine which items based on dates (I guess). Sometimes, I also do: for item in $(guix gc --list-dead | grep ) do guix gc -D $item done and you can pipe instead of for-looping. :-) Hope that helps, simon
Re: Questions regarding substitutes with debug output
zimoun writes: > Therefore, since your question is rooted from GWL: > > I need to specify the package programmatically as a string in > Guile. More specifically in the process packages field of Guix > Workflow Language. > > maybe GWL could also accept a symbol instead of a name string. Well, I > have not used GWL since many months and I do not remember but I think it > is doable. Ricardo? GWL accepts specifications or package values, so you could use (@ (my packages foo) gcc) to prefer that over some other package with the same name. -- Ricardo
Re: Setup a remote pair-programming environment
Hi Maxim, I am late to the party. :-) On Wed, 23 Feb 2022 at 21:19, Maxim Cournoyer wrote: >> That was fun, really fun (at least for me haha). >> I enjoy this way to share knowledge, demonstrate, mentor, etc. More >> than reading or watching content from you all. > > It sure sounds fun! It was really fun! :-) It is a really good way to learn both sides and also discuss some workflow tips barely discussed otherwise. However, it requires some time. I would recommend slots of 2h every week. From one session to the other, we “forgot” what we already did and weekly seems enough for not forgetting too much. ;-) And 2h means more or less only 1h of productive work, all the other is about tiny technical issues, resume, discuss tips, etc. I am really happy with the experience! Thanks Jérémy for the proposition! :-) >> One the communication side, Jitsi is fine. But there could be something >> more suited for remote pair-programming sessions. I read about a Jami >> service… > > As the jami-service-type implementer, I'd be happy to help you with > that, if you have any question setting it up, or issues after. At the time, the jami-service-type did not exist. ;-) Well, I know you are hosting a rendezvous point. Maybe it could be nice to add to the Cookbook both (how to setup a pair programming VM and how to setup a Jami rendezvous) could be really worth. Bah I have started to convert the Jérémy’s blog post to texi but then I have forgotten to submit the patch. Maybe I will resume… if no one beats me. ;-) It could be nice to have this “how to setup Jami” in the Cookbook. WDYT? Cheers, simon
Re: Questions regarding substitutes with debug output
Hi,
On Fri, 22 Apr 2022 at 10:29, Olivier Dion via wrote:
> On Fri, 22 Apr 2022, Maxim Cournoyer wrote:
>> Channels can only extend, not override the default Guix channel (the
>> world would be a bit of a mess if it did). So the easiest path is to
>> use a different name; alternatively for graph rewriting you could use
>> the various APIs to effect package transformations.
>
> Would be nice to have some way to specify channel in a package
> specification. I don't think that it would break things if we
> considerer channels as namespaces, i.e. different graph. A
> specification like:
>
> {channel}package@version:output
>
> would be useful. For now I will just rename them to "my/package".
What do you mean by «different graph»? From my understanding, the
additions of channels makes just the graph bigger: extending the initial
(upstream) graph with more nodes (channel). :-)
IIUC, the question is how to refer to these nodes, and from my
understanding, we use basically two ways:
1. by symbol; and thanks to Guile modules, this way provides
namespaces, somehow.
2. by metadata (name, version, output); and here I am not convinced it
is doable to have a namespace but maybe mimic it.
Therefore, since your question is rooted from GWL:
I need to specify the package programmatically as a string in
Guile. More specifically in the process packages field of Guix
Workflow Language.
maybe GWL could also accept a symbol instead of a name string. Well, I
have not used GWL since many months and I do not remember but I think it
is doable. Ricardo?
Last, back to the feature you would like – be able to write:
(specifications->manifest (list "foo"))
and select "foo" from your channel instead from upstream, right? Or a
way to specify the channel using the symbol from the name field in
, right?
Aside the syntax of the string – why not the one your are proposing –
and so adapt ’package-name->name+version’ (or similar), the function
’find-best-packages-by-name’ requires some improvements.
What I am missing is the mapping from channel name to package. Well,
Guix does not track this information at pull time. And I miss how to
implement such mapping.
Therefore, assuming this mapping, the package cache (%package-cache-file)
could be updated to also track such map. Such feature would also
simplify when searching; especially for variants (same as upstream but
other arguments).
WDYT?
Cheers,
simon
