Re: staging branch merged to master

Am Fri, Apr 14, 2023 at 03:29:01PM -0400 schrieb Maxim Cournoyer: > The staging branch has been merged to master. Thanks and congratulations! > Should we remove the branch from Cuirass and Guix, knowing that teams > is the way going forward? Definitely! I will go ahead and do so. If we want a st

Re: staging branch merged to master

Hello Maxim, On Fri, Apr 14, 2023 at 03:29 PM, Maxim Cournoyer wrote: > Hello, > > The staging branch has been merged to master. > Nice, thanks! > Should we remove the branch from Cuirass and Guix, knowing that teams > is the way going forward? I also agree with this change, yes to branches go

Re: staging branch merged to master

On Fri, Apr 14, 2023 at 03:29:01PM -0400, Maxim Cournoyer wrote: > The staging branch has been merged to master. Thanks! > Should we remove the branch from Cuirass and Guix, knowing that teams > is the way going forward? I am in favor!

Re: staging merge into master

Hi Maxim, On Wed, 12 Apr 2023 at 23:27, Andreas Enge wrote: > Am Wed, Apr 12, 2023 at 11:18:26PM +0200 schrieb Josselin Poiret: >> I don't have a particularly strong opinion either way, but if you do >> merge it, could you make sure to also merge master into c-u and launch a >> CI evaluation rig

Re: staging merge into master

Hi Andreas, Andreas Enge writes: > Hello Maxim, > > Am Wed, Apr 12, 2023 at 04:38:20PM -0400 schrieb Maxim Cournoyer: >> I'm planning to merge staging into master soon (tomorrow or friday), >> unless someone has a problem with it. It includes at least two CVE >> fixes as well as a bunch of upda

Re: staging merge into master

Hello, Josselin Poiret writes: > Hi Maxim, > > Maxim Cournoyer writes: > >> Hello, >> >> I'm planning to merge staging into master soon (tomorrow or friday), >> unless someone has a problem with it. It includes at least two CVE >> fixes as well as a bunch of updates such as a newer gstreamer,

Re: staging merge into master

Am Wed, Apr 12, 2023 at 11:18:26PM +0200 schrieb Josselin Poiret: > I don't have a particularly strong opinion either way, but if you do > merge it, could you make sure to also merge master into c-u and launch a > CI evaluation right afterwards? The second part is automatic right now, ci is config

Re: staging merge into master

Hello Maxim, Am Wed, Apr 12, 2023 at 04:38:20PM -0400 schrieb Maxim Cournoyer: > I'm planning to merge staging into master soon (tomorrow or friday), > unless someone has a problem with it. It includes at least two CVE > fixes as well as a bunch of updates such as a newer gstreamer, ffmpeg, > qt

Re: staging merge into master

Hi Maxim, Maxim Cournoyer writes: > Hello, > > I'm planning to merge staging into master soon (tomorrow or friday), > unless someone has a problem with it. It includes at least two CVE > fixes as well as a bunch of updates such as a newer gstreamer, ffmpeg, > qt 5, python-cryptography and a few

Re: 'staging' freeze

Hi, I'm really interested in Rust 1.60. Is there any progress on merging the staging branch? I see a lot of commits but I'm not sure whether we come closer to the merge or drifting away from it.

Re: 'staging' freeze

On Sun, Aug 28, 2022 at 05:56:08PM +0200, Mathieu Othacehe wrote: > > Hey Marius, > > > The 'staging' branch is in a pretty good shape, let's get it merged! > > Nice work! > > > I'm fairly rusty when it comes to Cuirass, and don't see a button to > > start the jobset here even when authenticate

Re: 'staging' freeze

Hey Marius, > The 'staging' branch is in a pretty good shape, let's get it merged! Nice work! > I'm fairly rusty when it comes to Cuirass, and don't see a button to > start the jobset here even when authenticated: > > https://ci.guix.gnu.org/jobset/staging > > Can someone remind me how to en

Re: ‘staging’ branch is open!

Ludovic Courtès writes: > Hopefully we’ll get a clearer picture in the coming days… There is starting to be some information in the QA data service instance: https://data.qa.guix.gnu.org/compare-by-datetime/package-derivations?base_branch=master&base_datetime=&target_branch=staging&target_d

Re: python-cryptography and rust [was: Re: ‘staging’ branch is open!]

Hello, Efraim Flashner skribis: > On Sun, May 15, 2022 at 11:22:05PM +0200, Ludovic Courtès wrote: [...] >> Yes, so what do you mean? Should we keep the old 3.3.1 for use on >> non-x86_64 platforms? Would that even work? > > I'll add 3.4.8 for non-x86_64 platforms and see if I can do somethi

Re: ‘staging’ branch is open!

Hi, zimoun skribis: > On Sun, 15 May 2022 at 22:55, Ludovic Courtès wrote: > >> I propose freezing tomorrow evening, Monday 16th ca. 8PM CEST. >> How does that sound? > > LGTM. The branch is now frozen and receive only fixes, right? An update: ci.guix wasn’t building much lately due to a bug

Re: ‘staging’ branch is open!

Hi, On Sun, 15 May 2022 at 22:55, Ludovic Courtès wrote: > I propose freezing tomorrow evening, Monday 16th ca. 8PM CEST. > How does that sound? LGTM. The branch is now frozen and receive only fixes, right? Note the «Aborted» status on . Cheers, simon

Re: python-cryptography and rust [was: Re: ‘staging’ branch is open!]

On Sun, May 15, 2022 at 11:22:05PM +0200, Ludovic Courtès wrote: > Hi Efraim, > > (+Cc: Marius.) > > Efraim Flashner skribis: > > > python-cryptography now depends on rust. We're going to need 3.4.8 from > > the 3.4 series for the other architectures. Currently > > python-cryptography@36.0.1 is

Re: python-cryptography and rust [was: Re: ‘staging’ branch is open!]

Hi Efraim, (+Cc: Marius.) Efraim Flashner skribis: > python-cryptography now depends on rust. We're going to need 3.4.8 from > the 3.4 series for the other architectures. Currently > python-cryptography@36.0.1 is gating about 3000 packages. Yes, so what do you mean? Should we keep the old 3.3

Re: ‘staging’ branch is open!

Hi Guix! Ludovic Courtès skribis: > zimoun skribis: > >> The schedule could be: >> >> + freeze the ’staging’ branch on the Sun May, 8th >> + fix until it is ready, targeting the Sun, May 22th >> + prepare a release for June > > So now I look ridiculous for being derailed myself… But yes, so

python-cryptography and rust [was: Re: ‘staging’ branch is open!]

python-cryptography now depends on rust. We're going to need 3.4.8 from the 3.4 series for the other architectures. Currently python-cryptography@36.0.1 is gating about 3000 packages. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality

Re: ‘staging’ branch is open!

Hi, On Sun, 08 May 2022 at 00:04, Ludovic Courtès wrote: > zimoun skribis: > >> The schedule could be: >> >> + freeze the ’staging’ branch on the Sun May, 8th >> + fix until it is ready, targeting the Sun, May 22th >> + prepare a release for June > > So now I look ridiculous for being deraile

Re: ‘staging’ branch is open!

Hi! zimoun skribis: > The schedule could be: > > + freeze the ’staging’ branch on the Sun May, 8th > + fix until it is ready, targeting the Sun, May 22th > + prepare a release for June So now I look ridiculous for being derailed myself… But yes, something like this offset by one (or two?) w

Re: ‘staging’ branch is open!

Hi, Ludovic Courtès writes: > Hi! > > The ‘staging’ branch is open! Which means that changes with “between > 300 and 1,800 rebuilds” (info "(guix) Submitting Patches") can go there; > now’s the time to (re)send package updates in that ballpark. Just to be clear, it was never closed :-). > Inc

Re: ‘staging’ branch is open!

Hi, On Sat, 30 Apr 2022 at 01:08, Ludovic Courtès wrote: > Incidentally, I was considering ungrafting things on that branch, even > those that go beyond the 1,800 dependents limit, since this is almost > always a safe change and ci.guix now has the capacity and stability > needed for that. Cool

Re: Staging branch [substitute availability]

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-

Re: Staging branch [substitute availability]

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 >

Re: Staging branch [substitute availability]

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

Re: Staging branch [substitute availability]

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

Re: Staging branch

Leo Famulari skribis: > The staging branch has been merged to master in commit > 75b775e81b5a81a59656eeba8811b42f45d503da > > Hooray! > > Thanks to everyone that helped out with bug reports, fixes, CI > assistance, etc. Yay! And thank *you* for coordinating this effort and working to get the br

Re: Staging branch

The staging branch has been merged to master in commit 75b775e81b5a81a59656eeba8811b42f45d503da Hooray! Thanks to everyone that helped out with bug reports, fixes, CI assistance, etc. There is some discussion about changes to the branch workflow: https://lists.gnu.org/archive/html/guix-devel/20

Re: staging on i686-linux

Leo Famulari writes: > On Sun, Jan 31, 2021 at 12:26:10AM -0500, Leo Famulari wrote: >> On Sun, Jan 31, 2021 at 01:06:45AM +0100, Ricardo Wurmus wrote: >> > I tried to upgrade my i686-linux system to staging. I reconfigured >> > successfully, but I had to hold back a package upgrade that depen

Re: staging on i686-linux

On Sun, Jan 31, 2021 at 12:26:10AM -0500, Leo Famulari wrote: > On Sun, Jan 31, 2021 at 01:06:45AM +0100, Ricardo Wurmus wrote: > > I tried to upgrade my i686-linux system to staging. I reconfigured > > successfully, but I had to hold back a package upgrade that depends on > > gst-plugins-good, wh

Re: staging on i686-linux

On Sun, Jan 31, 2021 at 01:06:45AM +0100, Ricardo Wurmus wrote: > I tried to upgrade my i686-linux system to staging. I reconfigured > successfully, but I had to hold back a package upgrade that depends on > gst-plugins-good, which fails its tests. Here is the relevant portion of the test log: -

Re: Staging branch [substitute availability]

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

Re: Staging branch [substitute availability]

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

Re: Staging branch [substitute availability]

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

Re: Staging branch [substitute availability]

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

Re: Staging branch [kwayland test failure]

On Wed, Jan 27, 2021 at 02:44:42PM -0500, Leo Famulari wrote: > On Wed, Jan 27, 2021 at 11:26:52AM +0100, Guillaume Le Vaillant wrote: > > It looks like the kwayland test failure on x86-64 doesn't happen all the > > time. > > I just built it successfully on master and on staging by trying again >

Re: Staging branch [kwayland test failure]

On Wed, Jan 27, 2021 at 11:26:52AM +0100, Guillaume Le Vaillant wrote: > It looks like the kwayland test failure on x86-64 doesn't happen all the time. > I just built it successfully on master and on staging by trying again > when the build failed. Thanks, that is useful info! I'll try building it

Re: Staging branch [kwayland test failure]

It looks like the kwayland test failure on x86-64 doesn't happen all the time. I just built it successfully on master and on staging by trying again when the build failed. signature.asc Description: PGP signature

Re: Staging branch [kwayland test failure]

On Tue, Jan 26, 2021 at 06:51:13PM -0500, Leo Famulari wrote: > kwayland is definitely broken on x86_64, so wayland users are invited to > fix it: > > -- > The following tests FAILED: > 26 - kwayland-testPlasmaWindowModel (Failed) > Errors while running CTest > make: *** [Makefile:

Re: Staging branch [substitute availability]

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

Re: Staging branch [substitute availability]

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

Re: Staging branch [problem with node-10.22]

On Sat, Jan 23, 2021 at 04:29:54PM -0500, Mark H Weaver wrote: > Presumably the problem is that you're using a certain 3rd-party channel > that relies upon the 'node-10.22' variable, which was removed in the > following commit on the 'ungrafting' branch (later merged into > 'staging'): > > https:/

Re: Staging branch [problem with node-10.22]

Jonathan Brielmaier writes: > I tried to update my desktop system to staging but it already fails in > `guix pull`: > > $ cat > /var/log/guix/drvs/d2/rd3sv1i0wy6bwibp4chjymz6b4dggl-guix-package-cache.drv.bz2 > | bzip2 -d > (repl-version 0 1 1) > Generating package cache for > '/gnu/store/pn96j52a

Re: Staging branch [problem with node-10.22]

On Sat, Jan 23, 2021 at 12:58:29PM +0100, Jonathan Brielmaier wrote: > I tried to update my desktop system to staging but it already fails in > `guix pull`: > > $ cat > /var/log/guix/drvs/d2/rd3sv1i0wy6bwibp4chjymz6b4dggl-guix-package-cache.drv.bz2 > | bzip2 -d > (repl-version 0 1 1) > Generating

Re: Staging branch [problem with node-10.22]

On Sat, Jan 23, 2021 at 12:58:29PM +0100, Jonathan Brielmaier wrote: > I tried to update my desktop system to staging but it already fails in > `guix pull`: > > $ cat > /var/log/guix/drvs/d2/rd3sv1i0wy6bwibp4chjymz6b4dggl-guix-package-cache.drv.bz2 > | bzip2 -d > (repl-version 0 1 1) > Generating

Re: Staging branch [problem with node-10.22]

On 22.01.21 21:46, Leo Famulari wrote: 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% i68

Re: Staging branch [substitute availability]

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

Re: Staging branch [substitute availability i686-linux]

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

Re: Staging branch [substitute availability armhf-linux]

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)

Re: Staging branch [substitute availability armhf-linux]

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-

Re: Staging branch [substitute availability aarch64-linux]

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.

Re: Staging branch [substitute availability aarch64-linux]

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

Re: Staging branch [substitute availability aarch64-linux]

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

Re: Staging branch [substitute availability armhf-linux]

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

Re: Staging branch [substitute availability armhf-linux]

> 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.

Re: Staging branch [substitute availability armhf-linux]

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

Re: Staging branch [substitute availability armhf-linux]

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

Re: Staging branch [substitute availability armhf-linux]

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

Re: Staging branch [substitute availability armhf-linux]

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

Re: Staging branch [substitute availability armhf-linux]

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

Re: Staging branch [substitute availability armhf-linux]

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

Re: Staging branch [substitute availability]

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,

Re: Staging branch [substitute availability armhf-linux]

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

Re: Staging branch [substitute availability armhf-linux]

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

Re: Staging branch [substitute availability armhf-linux]

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

Re: Staging branch [substitute availability armhf-linux]

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

Re: Staging branch [substitute availability i686-linux]

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

Re: Staging branch [substitute availability armhf-linux]

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,

Re: Staging branch [substitute availability i686-linux]

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. -

Re: Staging branch [substitute availability]

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

Re: Staging branch [substitute availability armhf-linux]

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

Re: Staging branch [substitute availability]

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

Re: Staging branch [substitute availability]

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

Re: Staging branch [substitute availability armhf-linux]

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

Re: Staging branch [substitute availability]

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

Re: Staging branch [substitute availability]

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

Re: Staging branch [substitute availability]

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

Re: Staging branch [substitute availability armhf-linux]

> 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

Re: Staging branch [substitute availability]

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

Re: Staging branch [substitute availability aarch64-linux]

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.

Re: Staging branch [substitute availability i686-linux]

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

Re: Staging branch [substitute availability aarch64-linux]

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

Re: Staging branch [substitute availability armhf-linux]

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

Re: Staging branch [substitute availability i686-linux]

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

Re: Staging branch [substitute availability x86_64-linux]

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

Re: Staging branch [substitute availability]

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

Re: Staging branch [i686]

mesa has failed to build for i686-linux on the staging branch, but there is no build log for this failure: -- builder for `/gnu/store/isx9ra95v8gw3fqgrvz62cwrlzl5s5y7-mesa-20.2.4' failed previously (cached) build of /gnu/store/26f51p9y1glpal0ik84qsyy5z7nqhc6w-mesa-20.2.4.drv failed Could not

Re: Staging branch [aarch64 failures]

On Wed, Jan 06, 2021 at 11:38:17AM +0100, Stefan wrote: > Hi Leo! > > > "while setting up the build environment: executing > > `/gnu/store/x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2/bin/guile': No > > such > > file or directory" > > > > Does anybody have advice? > > I have the same problem.

Re: Staging branch [aarch64 failures]

Hi Leo! > "while setting up the build environment: executing > `/gnu/store/x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2/bin/guile': No such > file or directory" > > Does anybody have advice? I have the same problem. See for a workaround. Bye Stefan

Re: Staging branch [aarch64 failures]

On Tue, Jan 05, 2021 at 02:01:35PM +0200, Efraim Flashner wrote: > qtbase built for me using qemu-binfmt emulation. Send it through again? I had Cuirass retry the build, and it failed immediately: https://ci.guix.gnu.org/build/163857/details The log file reads: "while setting up the build envir

Re: Staging branch [aarch64 failures]

On Tue, Jan 05, 2021 at 02:01:35PM +0200, Efraim Flashner wrote: > On Mon, Jan 04, 2021 at 08:37:44PM -0500, Leo Famulari wrote: > > The branch is building again! > > > > http://ci.guix.gnu.org/eval/10974 > > > > Qtbase is failing on aarch64: > > > > https://ci.guix.gnu.org/build/166439/details

Re: Staging branch [aarch64 failures]

On Mon, Jan 04, 2021 at 08:37:44PM -0500, Leo Famulari wrote: > The branch is building again! > > http://ci.guix.gnu.org/eval/10974 > > Qtbase is failing on aarch64: > > https://ci.guix.gnu.org/build/166439/details > > There errors like this: > > -- > g++ -c -pipe -O2 -w -fPIC -I. > -I/g

Re: Staging branch [aarch64 failures]

The branch is building again! http://ci.guix.gnu.org/eval/10974 Qtbase is failing on aarch64: https://ci.guix.gnu.org/build/166439/details There errors like this: -- g++ -c -pipe -O2 -w -fPIC -I. -I/gnu/store/48i8mxxb1v4x632dff3i1dbdhsazm8bw-mariadb-10.5.8-dev/include/mysql -I/gnu/store

Re: Staging branch

On Sat, Jan 02, 2021 at 08:38:27PM -0800, John Soo wrote: > For what it is worth I have rebased on staging and reconfiguring my > system on it built successfully. Also my manifest built successfully. Thank you very much for testing it. I'd glad to hear that everything is working for you.

Re: Staging branch

Hi Guix, Leo Famulari writes: > It is supposed to be running, but something has broken. This does happen > from time to time... Ah well... For what it is worth I have rebased on staging and reconfiguring my system on it built successfully. Also my manifest built successfully. I don't have ma

Re: Staging branch

On Sat, Jan 02, 2021 at 08:59:03AM -0800, John Soo wrote: > Is staging not running in ci?It looks like the last time it ran was just > before the rustfmt output of rust (commit 48926b5).Did changing rust@1.46 > somehow keep ci from running on staging? It is supposed to be running, but so

Re: Staging branch

Hi there, Is staging not running in ci?It looks like the last time it ran was just before the rustfmt output of rust (commit 48926b5).Did changing rust@1.46 somehow keep ci from running on staging? Maybe I am missing something. Any clues? John

Re: Staging branch

On Wed, Dec 30, 2020 at 03:24:02PM -0500, Leo Famulari wrote: > On Wed, Dec 30, 2020 at 10:57:39AM +0200, Efraim Flashner wrote: > > In the interest of getting staging merged soon-ish I think it's best to > > leave the kde-frameworks at 5.70 for now. A quick 'guix refresh -u -t > > kde' had a coupl

  1   2   3   >