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

Re: branch staging updated (5aeee07 -> 104151f)

On Sat, Jan 30, 2021 at 06:37:11PM -0500, Mark H Weaver wrote: > What would the Git hook do, precisely? The reason I ask is that some > bug fixes are appropriate on a frozen branch. How would a Git hook > determine whether a given commit should be allowed? I haven't given much thought to how it

staging on i686-linux

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

Re: branch staging updated (5aeee07 -> 104151f)

Leo Famulari writes: > The staging branch is frozen [0] so I reverted these commits and pushed > them to staging-next. > > I wonder what we can do to communicate the branch status. Right now it's > not easy to figure out, aside from asking around. Nicolas Goaziou > suggeste

Re: branch staging updated (5aeee07 -> 104151f)

On Fri, Jan 29, 2021 at 05:05:35PM -0500, guix-comm...@gnu.org wrote: > htgoebel pushed a change to branch staging > in repository guix. > > from 5aeee07 gnu: VLC: Remove obsolete patch. > new 9085260 guix: qt-build-system, qt-utils: Unify wrapping of > qt-programs.

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 bra

Re: Staging branch [substitute availability]

ould it take to connect at least one OverDrive? How can the admins among us help? Before, when Danny reported issues with emulated builds, we stopped all emulated builds for AArch64/ARMv7 to avoid further breakage. So I guess we should try to get back to that situation. > "guix time-mach

Re: Staging branch [substitute availability]

s because it took ~1.5 days for the CI to catch up, as you can see here: https://ci.guix.gnu.org/metrics. "guix time-machine --branch=staging -- weather" now reports 82.7% coverage for x86_64. > `guix weather` said to me that there are *no* queued builds for x86_64 > on staging

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 st

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

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: ***

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

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

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')

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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 > * st

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

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

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

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

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

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

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

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

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 wa

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

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:

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

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',

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 branc

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

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

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

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

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

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

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'

Re: Reconfigured on staging

On Sat, Jan 02, 2021 at 09:01:23PM +0200, Efraim Flashner wrote: > I've reconfigured my desktop on staging. Almost everything is working. > I'm running enlightenment on wayland, launched from sddm. > > In icecat, if I maximize the window the graphics stretch instead of > resi

Reconfigured on staging

I've reconfigured my desktop on staging. Almost everything is working. I'm running enlightenment on wayland, launched from sddm. In icecat, if I maximize the window the graphics stretch instead of resizing to the new window size. Then even if I switch back to "windowed mode" I

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 b

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

Re: Staging branch

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 couple of patches which didn't apply anymore and isn't > some

Re: Staging branch

> Thanks, Efraim! > > Let me know if I can help with that. 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 couple of patches which didn't apply anymore and isn't something I want to

Re: Staging branch

On Tue, Dec 29, 2020 at 04:00:16PM +0200, Efraim Flashner wrote: > These are mostly blocked by purpose and grantleetheme. I'll see if those > suddenly start building correctly if I upgrade the whole KDE stack. Thanks, Efraim! Let me know if I can help with that.

Re: Staging branch

On Tue, Dec 29, 2020 at 10:39:09AM +0200, Efraim Flashner wrote: > On Wed, Dec 23, 2020 at 05:46:25PM -0500, Leo Famulari wrote: > > On Wed, Dec 23, 2020 at 12:27:22AM -0500, Leo Famulari wrote: > > > > I tried using the newer version of this package (5.71) but it fails due > > to

Re: Staging branch

On Wed, Dec 23, 2020 at 05:46:25PM -0500, Leo Famulari wrote: > On Wed, Dec 23, 2020 at 12:27:22AM -0500, Leo Famulari wrote: > > ... and reply with any problems. > > The package kwidgetsaddons fails its test suite like this: > > -- > * Start testing of KColumnResizerTest * >

Re: Staging branch

On Wed, Dec 23, 2020 at 05:46:25PM -0500, Leo Famulari wrote: > On Wed, Dec 23, 2020 at 12:27:22AM -0500, Leo Famulari wrote: > > ... and reply with any problems. > > The package kwidgetsaddons fails its test suite like this: > > -- > * Start testing of KColumnResizerTest * >

Re: Staging branch

On Wed, Dec 23, 2020 at 12:27:22AM -0500, Leo Famulari wrote: > ... and reply with any problems. The package kwidgetsaddons fails its test suite like this: -- * Start testing of KColumnResizerTest * Config: Using QtTest library 5.15.2, Qt 5.15.2 (x86_64-little_endian-lp64

Re: Staging branch

On Sun, Dec 06, 2020 at 12:58:46PM -0500, Leo Famulari wrote: > The plan is to start building it next Friday, December 11. The staging branch is building: https://data.guix-patches.cbaines.net/repository/2/branch/staging/latest-processed-revision/package-substitute-availability It's mov

Re: Staging branch

Thank you! Let’s test!

Re: Staging branch

On Sun, Dec 13, 2020 at 02:12:59PM -0800, John Soo wrote: > As far as I understand it, it adds just enough to the rust package > definition to add the extra rustfmt output. Okay, I tweaked the commit message and pushed as 48926b588528c5a2b591e1e97a5757eb78d3cac1. Now the branch is

Re: Staging branch

As far as I understand it, it adds just enough to the rust package definition to add the extra rustfmt output.

Re: Staging branch

On Sun, Dec 13, 2020 at 01:50:35PM -0800, John Soo wrote: > The patch adds an extra output, leaving the compiler unchanged so nothing > should be effected in runtime as far as I know. But the patch does a lot more than just add another output, right?

Re: Staging branch

Hi Leo, The patch adds an extra output, leaving the compiler unchanged so nothing should be effected in runtime as far as I know. - John

Re: Staging branch

Hello, icecat, ungoogled-chromium, alacritty, ripgrep, exa and others depend on it at least. I have been using the patches for a few weeks. What do you think? - John

Re: Staging branch

On Sun, Dec 13, 2020 at 01:44:01PM -0800, John Soo wrote: > icecat, ungoogled-chromium, alacritty, ripgrep, exa and others depend on it > at least. I have been using the patches for a few weeks. > > What do you think? What I'm wondering is: does the patch make a simple change that is

Re: Staging branch

Leo Famulari writes: > On Sun, Dec 13, 2020 at 12:02:50PM -0800, John Soo wrote: >> Is there any chance this could make it to staging before the merge? >> >> http://issues.guix.gnu.org/42295 > > Can you clarify what it does (I'm not that familiar with Rust). &

Re: Staging branch

On Sun, Dec 13, 2020 at 12:02:50PM -0800, John Soo wrote: > Is there any chance this could make it to staging before the merge? > > http://issues.guix.gnu.org/42295 Can you clarify what it does (I'm not that familiar with Rust). Is it likely that things will "just work", or

Re: Staging branch

Hello there, Is there any chance this could make it to staging before the merge? http://issues.guix.gnu.org/42295 Thanks! John

Re: Staging branch

On Sun, Dec 06, 2020 at 12:58:46PM -0500, Leo Famulari wrote: > The plan is to start building it next Friday, December 11. Due to reasons, there are still a few more patches to be added to the branch. They should be pushed today. The plan is to work on the branch this week and complete it next

Re: Proposed change for the disruptive changes process (staging/core-updates)

Hi, On Fri, 23 Oct 2020 at 18:20, Christopher Baines wrote: > A simple process change that I think would help to address this is as > follows (I'll use core-updates as the example, but this applies for > staging as well): > > - core-updates is effectively renamed to co

Re: Staging branch

On Sun, Dec 06, 2020 at 03:20:50PM -0500, Leo Famulari wrote: > `guix refresh --list-dependents` doesn't dependencies that go through > build systems, unfortunately. You could do `git grep ruby-build-system > gnu/packages`, choose some test packages, and let the build farm sort > out the rest.

Re: Staging branch

On Sun, Dec 06, 2020 at 07:11:49PM +, Ryan Prior wrote: > It would be great if we can update the default Ruby to 2.7.2. Is there a > process for updating Ruby I can follow to help out? I don't know about Ruby in particular. The general process for updating a "compiler" package is to update

Re: Staging branch

On December 6, 2020, Leo Famulari wrote: > Are there any other changes we should make on [staging]? It would be great if we can update the default Ruby to 2.7.2. Is there a process for updating Ruby I can follow to help out?

Staging branch

Hello, I just pushed a fix for #40832 (alsa-lib cannot find its plugins) to a new 'staging' branch on Savannah. The plan is to start building it next Friday, December 11. Marius is planning to update Qt and Mesa in this round. Are there any other changes we should make on this branch? Leo

Proposed change for the disruptive changes process (staging/core-updates)

Hey, So, the process as I currently understand it, commits that cause lots of derivation outputs to change should be pushed to either the core-updates or staging branches, rather than master. Additionally, these branches should be periodically frozen (no one pushing new changes other than fixes

Re: staging freeze

Hi Marius, On Tue, 13 Oct 2020 at 23:54, Marius Bakke wrote: > I've pushed a set of updates to the long-overdue "staging" branch. > > Let's get it merged once Cuirass is done building for the various > architectures. Not sure how long that takes now that we no longer

<    1   2   3   4   5   >