Hi Guixers,
I'd like to announce that I'll start up the Guix meetups again next month
(March 2022).
See you at FOSDEM and Guix Days this month! :)
If you'd like to chat with us regarding the next meetups feel to reply
here or come chat with us at #whereiseveryone on the Libera Chat IRC network.
Hi Timothy,
On Thu, 03 Feb 2022 at 10:46, Timothy Sample wrote:
>> But the question is if Disarchive dissambles and preserves external
>> patches. Timothy?
[...]
> The bad news is that 0.75 is not there. At first I was going to
> apologize for the shortcomings of the sampling approach...
Hi Ricardo and Simon,
Ricardo Wurmus writes:
> The case of OpenBLAS is an anomaly in that this mechanism seems to
> produce different binaries dependent on where it is built. When I first
Thanks a lot for those explanations, I hadn't realized how peculiar
OpenBLAS is!
> Your problem is that
On Wed, Feb 02, 2022 at 11:43:57AM -0500, Maxim Cournoyer wrote:
> It's been 4 weeks, and nobody offered an opinion. I suggest we stick to
> upstream Linux LTS schedule and drop 4.4, otherwise we'll have even more
> variants to maintain.
Indeed. I don't think it's being used anyways.
The final
Hi zimoun,
zimoun writes:
> But the question is if Disarchive dissambles and preserves external
> patches. Timothy?
I have good news and bad news. :)
The good news is that some versions of this patch are in the PoG
database. There’s two versions of 0.76 and one of 0.72. Of those
three,
> zimoun schreef op do 03-02-2022 om 11:42 [+0100]:
> [...]
>
> > FWIW it's a known issue but I can't find it on issues.guix.gnu.org.
> > The (unimplemented) fix is to use worktrees, or don't checkout and use
> > the libgit2 / (guix git) equivalent of
> > "git show
Hi Konrad,
On Thu, 03 Feb 2022 at 10:16, Konrad Hinsen wrote:
>> CPU detection is a bottomless can of worms.
>
> That sounds very credible. But what can we do about this?
Well, I do not know what could be done about this. Today, the picture
for OpenBLAS@0.3.6 build looks like:
* Fail
Hi Konrad,
>> CPU detection is a bottomless can of worms.
>
> That sounds very credible. But what can we do about this?
>
> There is obviously a trade-off between reproducibility and performance
> here. Can we support both, in a way that users can understand and manage?
So far our default
Hi,
On Thu, 3 Feb 2022 at 10:21, Maxime Devos wrote:
> zimoun schreef op do 03-02-2022 om 03:19 [+0100]:
> > The issue is because concurrency. If two time-machines are run
> > concurrently, they both update ~/.cache/guix/checkouts/ and the end
> > result is hard to predict.
[...]
> FWIW it's
zimoun schreef op do 03-02-2022 om 03:19 [+0100]:
> The issue is because concurrency. If two time-machines are run
> concurrently, they both update ~/.cache/guix/checkouts/ and the end
> result is hard to predict.
>
> Well, I probably ran inside one terminal “guix time-machine
> --commit= --
Hi Ricardo and Simon,
Thanks for your insight! I didn't even know about lscpu. The output for
my laptop is shown below. I tried building on a virtual machine, and
that works fine.
> CPU detection is a bottomless can of worms.
That sounds very credible. But what can we do about this?
There is
11 matches
Mail list logo
