Hello!
Konrad Hinsen skribis:
>> Minor comments:
>>
>> • You write “Build systems are packages as well”. This could be
>> slightly misleading: build systems are (1) a set of packages, and
>> (2) a build procedure. Dunno if it makes sense to clarify that.
>
> Maybe I got something wro
Hi Marius,
On Sat, 11 Jan 2020 23:34:19 +0100
Marius Bakke wrote:
> There is a brand new staging branch on Savannah:
>
> https://git.savannah.gnu.org/cgit/guix.git/log/?h=staging
>
> Please submit your changes by Monday, January 19th.
That's not a Monday :-)
Should I update mrustc on staging
Pierre Neidhardt writes:
> Hooray!
>
> Thank you Marius, and thank you Mike for the tremendous effort!
>
>> Now we just need some packages using it! :-)
>
> We can get started with Qutebrowser.
Hello Pierre and Marius,
I've have sent some patches to an open bug #38148 in regards to
qutebrowse
Hello,
we are happy to announce a new post detailing the Guix participation
on the following round.
See https://guix.gnu.org/blog/2020/join-gnu-guix-through-outreachy/
Please spread the word!
Prospective mentors, please feel free to contact me should you have
any other proposals.
Mentor applic
Hi,
>> Questions:
>>
>> - Do manifests really need the store path?
>> - Same question about propagated-inputs. Aren't they already encoded in
>> the package definition? Why repeating them here?
>
> This ‘manifest’ file exists mostly for one purpose: to allow incremental
> operations on a pro
Hi Mike,
> I've have sent some patches to an open bug #38148 in regards to
> qutebrowser being outdated. I'm hoping this will help test out
> qtwebengine and close that bug. Two birds with one stone :)
Qutebrowser 1.9.0 works now, great job!
I've reviewed those patches; fix the few nits and I'll
Hi Ludo,
On Sun, 12 Jan 2020 at 00:48, Ludovic Courtès wrote:
> Note that it was never designed to be human-friendly. :-) The Scheme
> code passed to ‘--manifest’ is friendlier.
Why do not change a bit both /manifest and code accepted by
'--manifest' to have something consistent and human fri
Hi Pierre,
On Mon, 13 Jan 2020 at 15:02, Pierre Neidhardt wrote:
> So what's the take-away of this thread?
>
> 1. Simon suggested to add options to convert the manifest to the
> user-friendly specification file (i.e. something compatible with the
> --manifest option).
>
> What about this instead
If I understand correctly, it's because of the manifest files need
information like the store path and the propagated inputs, which are too
inconvenient for a user-facing "specification file."
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
> Those measures don't seem precise enough to draw a good conclusion.
> Could you increase the sample size (or maybe just loop?) so that all
> times reach over a second or so?
Indeed, my bad! Here are better timing results. I have repeated each of
the searches a 1000 times, and I'm getting around
On Mon, 13 Jan 2020 at 15:59, Pierre Neidhardt wrote:
>
> If I understand correctly, it's because of the manifest files need
> information like the store path and the propagated inputs, which are too
> inconvenient for a user-facing "specification file."
Hum? I am not convinced yet. :-)
For exam
zimoun writes:
> To me, the aim is to have something compliant between
> /manifest and --manifest. And compliant does not mean that
> /manifest is the entry point for the user specifications.
> What I find a bit odd is: today, --manifest accepts a DSL and Guix
> outputs to /manifest another DSL.
Hi Arun,
For sure, it is a good direction... but it is not that simple. :-)
On Mon, 13 Jan 2020 at 16:08, Arun Isaac wrote:
> > Those measures don't seem precise enough to draw a good conclusion.
> > Could you increase the sample size (or maybe just loop?) so that all
> > times reach over a se
Pierre Neidhardt writes:
> Christopher Baines writes:
>
>> Maybe sqlite is one to try initially. There's guile-sqlite3 for reading
>> and writing, and it can contain multiple tables as well as indexes for
>> fast searching.
>>
>>> Where would we store this database? In /var?
>>
>> Per user is
> 2. Send all other patches by using the "--in-reply-to=$ABOVE_MESSAGE_ID"
> option. Make sure the patches are in the right order on the command
> line. Example:
>
> git send-email --to=38...@debbugs.gnu.org \
> --in-reply-to='<20200113103304.9093-1-mike.ros...@gmail.com>' \
> 0002-patch-
Hello,
Ludovic Courtès writes:
> Hello!
>
> (Cc: maintainers.)
>
> Brett Gilio skribis:
>
>> Dec 30, 2019 3:34:22 PM Ludovic Courtès :
>>
>>> Guix-HPC is “institutional”, that’s part of the reason behind this.
>>> Regarding gitlab.inria.fr, that’s because it used to be hosted at Inria.
>>> Also
Pierre Neidhardt writes:
> Christopher Baines writes:
>
>>> Hmm, but this data relates to items in the store and online, they are
>>> global. Per-user would mean redundant packages and redundant (remote)
>>> queries.
>>
>> Yeah, maybe there's some way of optimising things for systems with
>>
Danny Milosavljevic writes:
> Hi Marius,
>
> On Sat, 11 Jan 2020 23:34:19 +0100
> Marius Bakke wrote:
>
>> There is a brand new staging branch on Savannah:
>>
>> https://git.savannah.gnu.org/cgit/guix.git/log/?h=staging
>>
>> Please submit your changes by Monday, January 19th.
>
> That's not a
Hi Pierre,
> We don't have OpenRA (https://www.openra.net/).
> Has anyone worked on it?
> Otherwise I'll go ahead.
>
> Any tip, any special wish?
I have a working package (last tested a while ago, some third party hashes
would need updaring, and there may be new build failures, but i played it
Hi simoun, Guix,
On +2020-01-13 18:54:18 +0100, zimoun wrote:
> Hi Arun,
>
> For sure, it is a good direction... but it is not that simple. :-)
>
>
> On Mon, 13 Jan 2020 at 16:08, Arun Isaac wrote:
>
> > > Those measures don't seem precise enough to draw a good conclusion.
> > > Could you in
20 matches
Mail list logo
