Hello everyone,
I have a problem with running Jami on an forein distribution - when I
try running Jami, I get the following message:
Locale not supported by C library.
Using the fallback 'C' locale.
terminate called after throwing an instance of 'std::runtime_error'
what(): locale::facet::_S_cre
zimoun writes:
> On Wed, 8 Jan 2020 at 22:50, Ludovic Courtès wrote:
>> Ricardo Wurmus skribis:
>
>> > On the other hand: this would need to be an ongoing effort. Newly
>> > introduced packages or even new features might create complex module
>> > cycles. It sounds tedious to keep track of
Hello,
kudos for the great article!
Ludovic Courtès writes:
[...]
> The format we use is Markdown fed to Haunt:
>
> https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/posts
>
> (which is sad because your Org file with Babel sessions is much nicer…).
> I think Pierre had som
Hi Ludo,
On Fri, 10 Jan 2020 at 17:59, Ludovic Courtès wrote:
> • In the ‘guix pack’ example, you could perhaps omit all the -S flags
> except for /bin, and mention ‘--save-provenance’.
I am the culprit.
The invocation of "guix pack -f docker" is not clear to me. So
basically, I copied/p
Hello!
zimoun skribis:
> Thank you!
> It was interesting. :-)
Glad you liked it. There were bumps on our Jitsi road in the middle,
but apart from that, I enjoyed chatting with everyone!
Now we should keep in touch with the Clojure folks to work on an
importer (I learned about “tools.deps”) an
Hello,
Efraim Flashner skribis:
> I wish 'guix challenge' by default challenged all the servers in the
> substitute-url list without needing to specify it with a flag and not
> just the default one (berlin)
All the servers in which list? The default list currently used by
guix-daemon? (Bad ne
Another thing that comes to mind: would it make sense to mention ‘guix
graph’ in the part where you pipe the output of ‘guix show’ to ‘recsel’,
etc.?
Ludo’.
Hi Konrad,
Konrad Hinsen skribis:
> Here is a first complete draft:
>
>
> https://github.com/khinsen/reproducibility-with-guix/blob/master/reproducibility-with-guix.org
>
> Feedback welcome, be it by mail or as issues on GitHub.
I’ve read it entirely and I think it’s perfect. It’s a pleasan
Hello!
The way I see it, we’re still toying with the idea and its pros and
cons—discussions about CLI syntax can come later. ;-)
The added flexibility of package parameters is definitely nice, but
really, maintainability is a big concern. The example Tobias gave (a
parameter to enable/disable X
Pierre Neidhardt writes:
> Christopher Baines writes:
>
>> Is there a specific thing you're interested in/unsure about?
>
> Well, mostly the patch continuous integration that you mentioned.
Cool, I'm hoping to have something more concrete by the upcoming Guix
Days!
> Regarding the documentati
Pierre Neidhardt writes:
> Christopher Baines writes:
>
>> So, to elaborate a bit more on the architecture I've had in mind for
>> dealing with the actual nars…
>>
>> I see the scope of the Guix Data Service extending as far as what nars
>> are available for outputs, and what outputs are associ
Hi Gábor,
On Fri, 10 Jan 2020 at 13:42, Gábor Boskovits wrote:
> > The modules graph (DAG) is already available. :-)
>
> The main problem here is that the modules do not form a DAG.
> There are circular dependencies between the modules.
> If those were not, then modular build would be possible,
Hello zimoun,
zimoun ezt írta (időpont: 2020. jan. 10., P, 13:10):
>
> Hi Gábor,
>
> Thank you for the explanations.
>
> Below, I am thinking loudly. :-)
>
> On Tue, 7 Jan 2020 at 21:14, Gábor Boskovits wrote:
>
> > > > Gábor once suggested an iterative approach of identifying the most
> > > > i
Hi Christopher,
Thanks for the details!
Christopher Baines writes:
> Is there a specific thing you're interested in/unsure about?
Well, mostly the patch continuous integration that you mentioned.
Regarding the documentation, it'd be nice to explain _what_ can be done
with Guix Data Service, s
Hi Ludo,
On Wed, 8 Jan 2020 at 22:50, Ludovic Courtès wrote:
> Ricardo Wurmus skribis:
> > On the other hand: this would need to be an ongoing effort. Newly
> > introduced packages or even new features might create complex module
> > cycles. It sounds tedious to keep track of this and to enfo
Hi Gábor,
Thank you for the explanations.
Below, I am thinking loudly. :-)
On Tue, 7 Jan 2020 at 21:14, Gábor Boskovits wrote:
> > > Gábor once suggested an iterative approach of identifying the most
> > > important nodes in the package graph that should be moved to their own
> > > modules, so
16 matches
Mail list logo
