Hey,
> The network team asks me to test it now. Could you please give it a
> try?
I ran a few tests, it seems to work perfectly! It's really impressive
how Wireguard is easy to set up. I think it deserves a complete Guix
service :).
--8<---cut here---start-
Mathieu Othacehe writes:
>> Yes, this should be okay. Does this mean that we can get rid of all the
>> other ports that we previously requested?
>
> Yes, the SSH tunnels and the associated open ports shouldn't be useful
> anymore, as we'll be able to route all the build nodes traffic through
>
Hello,
> Yes, this should be okay. Does this mean that we can get rid of all the
> other ports that we previously requested?
Yes, the SSH tunnels and the associated open ports shouldn't be useful
anymore, as we'll be able to route all the build nodes traffic through
the VPN.
> If you’re sure
Hi Mathieu,
sorry for missing this message (and all the others).
Leo pointed me to this message on IRC. (Thanks!)
> The easier way to proceed could be to create a VPN for the remote build
> machines that are not on berlin local network. Wireguard could be a good
> candidate. That would mean th
Hello,
> What would it take to connect at least one OverDrive? How can the
> admins among us help?
I have reconfigured the overdrive1 so that it runs a Cuirass remote
worker. Now several ports on berlin and the overdrive1 need to be opened
for the remote building mechanism.
The easier way to
On Tue, Jan 26, 2021 at 06:51:13PM -0500, Leo Famulari wrote:
> On Fri, Jan 22, 2021 at 03:46:45PM -0500, Leo Famulari wrote:
> > --
> > master branch
> > aarch64: 72%
> > x86_64: 94%
> > i686: 86%
> > armhf: 46%
> >
> > staging branch
> > aarch64: 48%
> > x86_64: 79%
> > i686: 70%
> > arm
Hi Mathieu,
Mathieu Othacehe skribis:
> I have not connected the overdrives yet, so the aarch64 builds are still
> 100% emulated. Regarding x86_64, I guess it's because it took ~1.5 days
> for the CI to catch up, as you can see here:
> https://ci.guix.gnu.org/metrics.
What would it take to conn
Hey Leo,
> So, minor improvements to aarch64, but x86_64 is actually worse!
> Mathieu, I'm curious, are we using the overdrives again? Or still
> emulating aarch64?
I have not connected the overdrives yet, so the aarch64 builds are still
100% emulated. Regarding x86_64, I guess it's because it
On Fri, Jan 22, 2021 at 03:46:45PM -0500, Leo Famulari wrote:
> --
> master branch
> aarch64: 72%
> x86_64: 94%
> i686: 86%
> armhf: 46%
>
> staging branch
> aarch64: 48%
> x86_64: 79%
> i686: 70%
> armhf: 30%
> --
Updates since the recent merge of master into staging:
--
master
Hi,
> Freetype issue is fixed in version 9, but that
> has other problems, such as making it impossible to unbundle the dozens
> of libraries that we are currently unbundling [...] it is possible to
> backport the VTK commits that fix Freetype compatibility, but it will be
> a lot of work and a hu
On Wed, Jan 13, 2021 at 05:30:53PM -0500, Leo Famulari wrote:
> Using `guix weather`, we can check substitute availability for the
> staging branch:
>
> --
> master branch
> aarch64: 66%
> x86_64: 93%
> i686: 85%
> armhf: 51%
>
> staging branch
> aarch64: 44%
> x86_64: 80%
> i686: 60%
> a
On Wed, Jan 13, 2021 at 07:22:35PM -0500, Leo Famulari wrote:
> I've reported this upstream:
>
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/4091
Upstream cannot reproduce the test failure.
I disabled the test in commit 8b55544212a90b0276df49596a3d373e5c2e8f5c
and now mesa has built for i6
Sorry, I forgot to attach that config.(use-modules (gnu bootloader)
(gnu bootloader u-boot)
(gnu services base)
(gnu system)
(gnu system image)
(gnu system file-systems)
(guix channels)
(guix inferior)
Hi,
> > LCD output, nothing answering on serial console (@1.5Mbps
> > (uboot speed) or 115.2Kbps (kernel speed, I think)).
Both kernel and u-boot use 150 baud.
> Strange, seems that Caliph did manage to get a serial console. Caliph,
> any insight here?
A configuration close to the pinebook-
On Mon, Jan 18, 2021 at 12:19:59PM +0200, Efraim Flashner wrote:
> Just finished building llvm, took 14.5 hours and RAM+swap went over
> 3.5GB at certain points that I checked.
Wow! Thank you very much for checking.
Just finished building llvm, took 14.5 hours and RAM+swap went over
3.5GB at certain points that I checked.
On Sun, Jan 17, 2021 at 09:50:27PM +0200, Efraim Flashner wrote:
> On Wed, Jan 13, 2021 at 06:38:39PM -0500, Leo Famulari wrote:
> > For aarch64-linux, the biggest problems are LLVM and Rust
On Wed, Jan 13, 2021 at 06:38:39PM -0500, Leo Famulari wrote:
> For aarch64-linux, the biggest problems are LLVM and Rust, but there are
> other major problems such as nss-certs.
>
> Are LLVM and Rust expected to work on this platform within Guix? What
> about GHC?
llvm should work, I'll start a
On Sun, Jan 17, 2021 at 12:01 PM Mathieu Othacehe wrote:
> you should be able to download this image.
Yep, I DL'ed and got the same result as with my own images, so my
building is not be the problem.
> Yes looks like the search pagination and ordering is broken, those are
> definitely bugs that
> That's slightly different than what I have been doing, but
> the resulting image has the same problem than mine, no
> LCD output, nothing answering on serial console (@1.5Mbps
> (uboot speed) or 115.2Kbps (kernel speed, I think)).
Strange, seems that Caliph did manage to get a serial console.
On Sun, Jan 17, 2021 at 11:17 AM Mathieu Othacehe wrote:
> --8<---cut here---start->8---
> guix build -f pinebook.scm
> --8<---cut here---end--->8---
>
> should achieve the same result locally.
That's slightly different than
Hello,
> trying to DL (in browser or with wget) the build output, by using
> the "https://ci.guix.gnu.org/download/190783"; link, I get:
> error "Could not find the request build product."
Oh, it's already been garbage collected on Berlin, sorry about that
:(. I'll see what I can do. In the mean
Hello,
Thanks
On Sun, Jan 17, 2021 at 10:35 AM Mathieu Othacehe wrote:
> You can download the latest Pinebook Pro image here:
>
> https://ci.guix.gnu.org/build/190783/details
trying to DL (in browser or with wget) the build output, by using
the "https://ci.guix.gnu.org/download/190783"; link, I
Hello Vincent,
You can download the latest Pinebook Pro image here:
https://ci.guix.gnu.org/build/190783/details
to search for the latest images:
https://ci.guix.gnu.org/search?query=spec%3Aguix-master+system%3Ax86_64-linux+status%3Asuccess+pinebook-pro
Thanks,
Mathieu
Hello,
> > I even attempted building the pinebook pro image without success.
>
> Hm... it's a shame we are building this and it doesn't work.
I only tried my locally built one, is there a substitute that I can try ?
That would tell if the problem is on my side or not.
> Do you also use some armh
On Fri, Jan 15, 2021 at 09:27:36AM +0100, Vincent Legoll wrote:
> On Fri, Jan 15, 2021 at 12:07 AM Leo Famulari wrote:
> > Specifically about armhf, if anybody wants to use it with Guix, I hope
> > they will speak up.
>
> I am interested, I have tried, and failed to get anything (apart from guix
Mathieu Othacehe writes:
> Now, how to move on?
>
> First, I still need to connect the four overdrives machine to the new
> Cuirass remote building mechanism, and I would need some help for that
> (asked on guix-sysadmins). But, I'm not sure it will much improve the
> situation.
>
> Longer term,
Hello,
On Fri, Jan 15, 2021 at 10:54 AM Mathieu Othacehe wrote:
> It seems that Caliph Nomble succeeded to build a Pinebook Pro image and
> booted it, without graphics, after a few fixes:
> https://issues.guix.gnu.org/45584.
>
> You may want to try again :).
DONE, it's a bit better, this time in
Hello Vincent,
> I even attempted building the pinebook pro image without success.
It seems that Caliph Nomble succeeded to build a Pinebook Pro image and
booted it, without graphics, after a few fixes:
https://issues.guix.gnu.org/45584.
You may want to try again :).
>> There is almost no arm
Hey Ludo,
> You seem to imply that the issue is the number of architectures, rather
> than the small number of ARMv7 build machines (now that we disabled
> 32-bit builds on AArch64). Do I get it right?
Yes my point is that building three specifications on three
architectures, including an emul
Hello,
On Fri, Jan 15, 2021 at 12:07 AM Leo Famulari wrote:
> Specifically about armhf, if anybody wants to use it with Guix, I hope
> they will speak up.
I am interested, I have tried, and failed to get anything (apart from guix
on foreign armbian). But I am more interested in guixsd though.
I
On Thu, Jan 14, 2021 at 11:37:39PM +0100, Ricardo Wurmus wrote:
>
> Leo Famulari writes:
>
> > For i686-linux:
> >
> > Should we even be attempting to build Rust on this platform? Has it ever
> > worked? What about the ant-bootstrap?
> […]
> >580 ant-bootstrap@1.8.4
> > /gnu/store/rb0r
On Thu, Jan 14, 2021 at 09:44:17AM +0100, Mathieu Othacehe wrote:
> Your weather summary is a great idea, thanks! As I said in my previous
> email, the armhf substitutes are not built right now on the CI. It's
> really sad but we have to make an impossible choice between:
Specifically about armhf,
Leo Famulari writes:
> For i686-linux:
>
> Should we even be attempting to build Rust on this platform? Has it ever
> worked? What about the ant-bootstrap?
[…]
>580 ant-bootstrap@1.8.4
> /gnu/store/rb0r3r4vf3gd63bqinpkha9450yzvjm6-ant-bootstrap-1.8.4
This should work on i686 IIRC.
-
Mathieu Othacehe skribis:
> Since the introduction of the "wip-offload" branch on Cuirass, the
> situation has much improved. The workers are constantly building. For
> now we are building three specifications:
>
> * guix-modular-master
> * guix-master
> * staging
Yay!
> for x86_64, i686 and aa
Hi,
Mathieu Othacehe skribis:
> Your weather summary is a great idea, thanks! As I said in my previous
> email, the armhf substitutes are not built right now on the CI. It's
> really sad but we have to make an impossible choice between:
>
> * Trying to build everything on all architecture and ha
Mathieu,
Mathieu Othacehe 写道：
As I said, the new remote building Cuirass mechanism is not yet
deployed
on those machines and I would need someone with login access to
reconfigure those machines for me.
I reconfigured dmitri and have now also restarted guix-daemon.
Is there anything more I ne
Hello Jonathan,
> I can not speak for Nix, but openSUSE has around 10 more or less powerful ARM
> servers for native building. See https://build.opensuse.org/monitor
Thanks for sharing, I like very much the design of this page, I might
take some ideas from it to improve https://ci.guix.gnu.org
Hi Mathieu,
I have not read carefully all the emails on the topic, so I am
probably out-of-scope.
On Thu, 14 Jan 2021 at 09:44, Mathieu Othacehe wrote:
> * Trying to build everything on all architecture and have the CI that is
> awfully lagging behind.
>
> * Restrict the number of architectur
Hello Tobias,
> I don't think it's obvious and I don't think it's true.
Well obvious was a poor choice of word. But I've been spending several
weeks/months monitoring Berlin and I think I'm starting to have a good
overview of the situation.
This new page[1] shows what the build machines are do
Mathieu!
Mathieu Othacehe 写道：
Longer term, we need to figure out a better solution. It's now
obvious that we do not have the computation power to build all
our
branches for 5 different architectures
I don't think it's obvious and I don't think it's true.
relying heavily on emulation for ar
Am Thu, 14 Jan 2021 09:39:41 +0100, Mathieu Othacehe schrieb:
> First, I still need to connect the four overdrives machine to the new
> Cuirass remote building mechanism, and I would need some help for that
> (asked on guix-sysadmins). But, I'm not sure it will much improve the
> situation.
>
> Lon
> The armhf-linux platform is in the worst shape, both on the master and
> staging branches. It's a shame because it's also the least powerful,
> with almost no hardware thermally capable of sustained CPU usage, so
> users will have the worst experience building packages for it.
>
> Does anyone w
Hello Leo,
> --
> master branch
> aarch64: 66%
> x86_64: 93%
> i686: 85%
> armhf: 51%
>
> staging branch
> aarch64: 44%
> x86_64: 80%
> i686: 60%
> armhf: 30%
> --
Thanks for the figures. I can comment on some stuff. Until recently it
was hard to monitor the build farm status becaus
I’ve been working on ghc and making some progress. I’d love to have more
support for rust but I’m not sure what the issue is.
On Wed, Jan 13, 2021 at 06:33:04PM -0500, Leo Famulari wrote:
> The mesa test suite failure is reproducible, and it looks like this:
>
> --
> 23:07:53 /tmp/guix-build-mesa-20.2.4.drv-0/build/src/util/u_debug_stack_test
> --- stdout ---
> Running main() from ../mesa-20.2.4/src/gtest/src/gtest_m
For aarch64-linux, the biggest problems are LLVM and Rust, but there are
other major problems such as nss-certs.
Are LLVM and Rust expected to work on this platform within Guix? What
about GHC?
--
3509 packages are missing from 'https://ci.guix.gnu.org' for 'aarch64-linux',
among which:
21
The armhf-linux platform is in the worst shape, both on the master and
staging branches. It's a shame because it's also the least powerful,
with almost no hardware thermally capable of sustained CPU usage, so
users will have the worst experience building packages for it.
Does anyone want to work o
For i686-linux:
Should we even be attempting to build Rust on this platform? Has it ever
worked? What about the ant-bootstrap?
The mesa test suite failure is reproducible, and the error messages are
found below.
--
2286 packages are missing from 'https://ci.guix.gnu.org' for 'i686-linux',
a
Here is the "missing package" report printed by `guix weather
--coverage=10` for x86_64-linux.
The Java packages at the top of this list are private packages, but
substitutes are available for them. Maybe they should be public, but
hidden?
Overall, I think the staging branch is ready for x86_64
Using `guix weather`, we can check substitute availability for the
staging branch:
--
master branch
aarch64: 66%
x86_64: 93%
i686: 85%
armhf: 51%
staging branch
aarch64: 44%
x86_64: 80%
i686: 60%
armhf: 30%
--
So, substitute availability is definitely lower on the staging branch.
It
50 matches
Mail list logo
