I reconfigured my Guix System based on core-updates, and afterwards I
was unable to login, either remotely over SSH, or on the Linux console.
After cutting the power to the computer and turning it back on, I was
able to log in.
I've attached my configuration file for your reference.
;; This is an
On Sun, Apr 26, 2020 at 08:05:34PM +0300, Efraim Flashner wrote:
> I squashed all the cargo commits together and pushed them. I didn't push
> the one with adding rav1e to ffmpeg, I wasn't sure how much that would
> add to 'guix size'.
Amazing, thank you!!!
I intended the FFmpeg commit as a "demo"
On Sun, Apr 26, 2020 at 08:05:34PM +0300, Efraim Flashner wrote:
> I squashed all the cargo commits together and pushed them. I didn't push
> the one with adding rav1e to ffmpeg, I wasn't sure how much that would
> add to 'guix size'.
It's okay to delete the wip-rav1e branch now, right?
signatur
On Tue, Apr 28, 2020 at 03:17:06PM +0200, Marius Bakke wrote:
> Leo Famulari writes:
>
> > I reconfigured my Guix System based on core-updates, and afterwards I
> > was unable to login, either remotely over SSH, or on the Linux console.
>
> Do you still have the logs fro
On Mon, May 04, 2020 at 09:31:46AM -0400, Maxim Cournoyer wrote:
> There's a new blog post about a recent update to the GNU Guix maintainer
> collective [0]. I won't repeat the blog post here, but in a few words,
> Ricardo Wurmus is stepping down from his role and Mathieu Othacehe
> is joining in.
On Wed, May 06, 2020 at 06:27:31PM +0200, Vincent Legoll wrote:
> From the manual or from the CI, to let the build farm do more useful things
> I'm not against, but is it really making maintenance difficult by still being
> in
> the codebase ?
It's not really a maintenance burden currently since
On Wed, May 06, 2020 at 06:27:31PM +0200, Vincent Legoll wrote:
> I grabbed a gnubee during the crowdfunding campaign, but the CPU
> is too low spec to do a lot of compilation on it.
I'm not an expert on MIPS but I *think* the GnuBee uses a different
architecture than what Guix was ported to.
So,
On Mon, May 11, 2020 at 09:50:57PM +0200, Pierre Neidhardt wrote:
> I'm planning to work on a probably-GTK graphical installer as part of
> the NLNet grant I've received in the coming month. Let's keep in touch!
Congratulations!
signature.asc
Description: PGP signature
On Wed, May 13, 2020 at 03:08:26AM +0200, zimoun wrote:
> Based on these 2 messages [1,2], what is the consensus between
> git-fetch and url-fetch?
Do we need a consensus? Sometimes it's enough for the reviewer to 1)
bite their tongue or 2) fix before pushing. Often it's a matter of taste
and it i
On Sun, May 17, 2020 at 04:50:12PM +0200, Marius Bakke wrote:
> This is a hack to make (some) fonts working when users don't have fonts
> specified in their system configuration, and (crucially) places where
> the fontconfig cache may be unavailable such as 'guix pack's.
>
> I'm not sure whether f
On Wed, May 20, 2020 at 01:28:13PM +0200, Marius Bakke wrote:
> The print infrastructure (CUPS, ghostscript) does not use Pango, so I
> think gs-fonts still work there.
>
> Might be difficult to work with when the end user applications don't
> recognize them though.
>
> What do you expect from a
On Thu, May 21, 2020 at 11:06:08PM +0200, Marius Bakke wrote:
> Hello Guix,
>
> The installer has seen a few bugfixes since the 1.1.0 release, and
> guix-install.sh has also had a face lift. Not to mention the big
> "core-updates" merge that broke everyones fonts, but also brought
> goodies such
On Fri, May 22, 2020 at 10:44:48PM +0200, Ludovic Courtès wrote:
> Hello Guix!
>
> I think we should change our pre-push hook as shown below.
>
> Thoughts?
Is it fast? :)
On Mon, May 25, 2020 at 01:13:16PM -0700, Vagrant Cascadian wrote:
> Wait a minute... you're saying this is something that needs to be
> configured on each committer's machine(s)?
Yes, it was recommended in HACKING and then, after we removed that file,
in the Commit Access section of the manual. W
On Tue, May 26, 2020 at 01:27:40PM -0400, Christopher Lemmer Webber wrote:
> So this page explains the problem:
>
>
> https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines
>
> "Problem: Recommends non-free addons and plugins; automatically
On Sat, May 30, 2020 at 11:28:08PM +0200, Marius Bakke wrote:
> raingloom writes:
>
> > Hey all!
> >
> > So, I recently gave a go to packaging EDK2 on my channel, and found out
> > that it requires several submodules, including OpenSSL, which take up
> > quite a bit of space and take way longer t
On Thu, Jun 18, 2020 at 11:31:07PM +0200, zimoun wrote:
> - What is the status of "alsa-lib cannot find its plugin"?
The patch works (last time I tested a couple weeks ago) but I would
really like a review of the C-language parts of the patch.
signature.asc
Description: PGP signature
On Mon, Jun 22, 2020 at 06:06:44PM +0100, Christopher Baines wrote:
> It seems like you got further in understanding this than I did. Given
> that this seems like a test failure, and I don't think there's anything
> to suggest that the actual functionality doesn't work, the course of
> action I see
On Sat, Jun 27, 2020 at 12:59:36AM +0200, bre...@posteo.net wrote:
> I think some of you may member me. I am a committer to the Guix project who
> took a hiatus after my son was born. I am returning from that hiatus and
> would love to begin contributing again.
Welcome back!
Please upload your ne
On Sat, Aug 08, 2020 at 11:30:40PM -0400, Mark H Weaver wrote:
> Note that the default kernel configurations for 5.8 still need to be
> added. Leo, would you like to work on that?
I'm planning to do that when the 5.8 kernel becomes the "stable" kernel.
I assume this will happen soon.
On Tue, Aug 18, 2020 at 08:38:39PM +0200, HiPhish wrote:
> My first question is regarding `guix git authenticate`. The first time I ran
> it
> after a `git clone ...` and `guix environment guix` I got an error saying
> that
> the `keyring` branch cannot be found. So I did a `git checkout --trac
On Fri, Aug 21, 2020 at 10:51:29PM +0200, HiPhish wrote:
> OK, I'll try that. My main concern was with packages I actually want to run.
> For example, last time I wanted to update the Neovim version, so I changed
> the
> definition and installed Neovim in order to try it out a bit. But doing so
Hi,
I have started handling major updates of linux-libre for Guix, starting
with version 5.7 (collaborators are invited!).
I didn't read this discussion because it's quite long and I don't
perceive that anything needs to change with how we package linux-libre.
It has worked well for several years
On Tue, Aug 25, 2020 at 05:01:07PM -0400, Leo Famulari wrote:
> If there are concrete problems to report or changes to request, please
> let us know by opening a bug ticket at , or by sending
> a patch to .
I'd like to explain more clearly what I meant by my last message.
First,
On Tue, Aug 25, 2020 at 06:23:19AM -0400, guix-comm...@gnu.org wrote:
> This commit enables GZIP compression for linux-libre kernel modules,
> reducing
> the size of linux-libre by 63% (165MB).
Nice!
>
> * gnu/packages/aux-files/linux-libre/5.8-arm.conf: Enable GZ compression.
>
On Sun, Sep 13, 2020 at 12:04:11AM +0800, Zhu Zihao wrote:
> Hi everybody. I' m packaging digikam(https://digikam.org). A free photo
> management software from KDE project. There're 2 dependecies missing from
> current Guix(qtav & libksane)
>
>
> I tried to package qtav(https://github.com/wang-
I just pushed commit 51eb3e11 [0], bringing our linux-libre kernel
packages up to date.
It's September 30 here. The commit is dated September 28, because that's
when I made it. These kernels were released upstream on September 26.
Personally, I am okay with the risks implied by this kind of time
On Tue, Oct 06, 2020 at 06:12:15AM +0900, Yasuaki Kudo wrote:
> Just out of curiosity, is it the case if only Linux Kernel team itself
> separated the controversial (with GNU folks, at least 😄) aspect of
> Linux as some build option, we don't have to maintain this
> "LinuxLibre" in the first place?
On Mon, Oct 05, 2020 at 03:53:05PM +0200, Ludovic Courtès wrote:
> What update, build, and testing recipe would you recommend to someone
> willing to help?
I boot a `guix system vm` using the latest stable kernel, and also build
the sources of the rest of the kernels. I also do the "basic" system
On Wed, Oct 07, 2020 at 06:32:34AM +0900, Yasuaki Kudo wrote:
> But I was intrigued, that it felt like a situation where a vegetarian would
> order a pizza from a restaurant that doesn't offer a vegetarian option so he
> has to painstakingly remove meat from it, while it would have been better if
On Thu, Oct 29, 2020 at 09:24:08AM +0100, Tobias Geerinckx-Rice wrote:
> Raghav!
>
> Raghav Gururajan 写道：
> > I think it is good to have a package-variable "linux-libre-lts", as
> > mentioned in the table at https://jxself.org/linux-libre/
>
> It is! Would you like to try your hand at a patch?
On Sun, Nov 01, 2020 at 02:35:50PM -0500, Morgan Smith wrote:
> I would like to propose that we move towards using sources that resemble
> the development sources as closely as possible.
>
> I like to work on Emacs and Emacs packages in my spare time. The Guix
> package transformations are gold fo
On Tue, Nov 03, 2020 at 01:59:56AM +0100, yarnton--- via Development of GNU
Guix and the GNU System distribution. wrote:
> A slightly annoying aspect of Guix that IMHO should be improved is download
> speed. I haven't inspected any code, but it seems to me that Guix is
> reopening a connection f
On Tue, Nov 03, 2020 at 05:51:49PM +0100, yarnton--- via Development of GNU
Guix and the GNU System distribution. wrote:
> > https://issues.guix.gnu.org/39728
> >
> Can I help testing this patch?
Yes, the steps required for this are outlined in the manual chapter
Contributing — specifically the
On Sun, Nov 08, 2020 at 03:27:17PM +0100, Tanguy Le Carrour wrote:
> `pep517` keeps on trying to download dependencies, which won't work.
That usually means that the software is missing some dependencies. If
you think they should be available in the build environment,
double-check that they are, a
On Mon, Nov 09, 2020 at 02:18:21PM +0100, Simon Josefsson via Development of
GNU Guix and the GNU System distribution. wrote:
> * gnu/packages/authentication.scm (oath-toolkit): Update to 2.6.3. Drop
> patch.
Thanks!
> - (patches
> -(append (search-patches "oath-toolkit-glibc-com
On Tue, Nov 10, 2020 at 04:11:55PM +0100, Simon Josefsson wrote:
> Thanks for the review! How about this updated patch?
Thank you!
> From 7c57d7b93f1315ff02e55d11d41b8c9442bb7633 Mon Sep 17 00:00:00 2001
> From: Simon Josefsson
> Date: Tue, 10 Nov 2020 16:10:17 +0100
> Subject: [PATCH] gnu: oat
On Mon, Nov 16, 2020 at 05:35:02PM +0100, Jonathan Brielmaier wrote:
> Hi fellow Guix hackers,
>
> I'm happy to announce that effective of today I have commit access to our
> git repository.
Welcome aboard!
signature.asc
Description: PGP signature
On Mon, Nov 23, 2020 at 11:01:54PM +0100, zimoun wrote:
> PS: The ugly missing thing with online is «drink and party»
> (socializing). :-) Well, one idea that popped up had been: people from
> the same city could join, when possible. But lockdown complicated
> everything, at least in Paris.
I rea
On Tue, Nov 24, 2020 at 09:13:38PM +0530, Arun Isaac wrote:
> I'm happy it was an online event and I could participate. I live in
> India and travelling to Europe is a bank-breaking endeavour that is
> normally out of the question. I think even future offline Guix Days,
> after the pandemic, should
On Tue, Nov 24, 2020 at 12:12:52AM -0300, Magali Lemes wrote:
> Hi, Raghav.
>
> thank you. I'm really looking forward to this internship.
Welcome!
On Tue, Nov 24, 2020 at 09:26:37PM +0100, raingloom wrote:
> My only issue was that I had to reconnect audio every 3-4 minutes,
> sometimes having to do a full reload. BBB was nice, but apparently it's
> still pretty heavy.
Can you say what web browser you were using? Bonus points if you can
give
On Wed, Nov 25, 2020 at 02:19:17PM +0100, zimoun wrote:
> Since this historical place would not change* “soon”, first because we
> like it (I speak for myself) and second because it is accommodating,
> ideas to deal with poor network are welcome. :-)
The standard solution is to do cellular network
On Wed, Nov 25, 2020 at 03:02:28PM +0100, zimoun wrote:
> Hi,
>
> Cool for the change!
>
> On Wed, 25 Nov 2020 at 14:27, Danny Milosavljevic
> wrote:
>
> >> I only removed trailing #t in a couple of files unlikely to result in
> >> merge conflicts down the road, as Marius rightfully suggested
On Wed, Nov 25, 2020 at 06:50:41PM +0100, Michael Rohleder wrote:
> Browser is icecat 78.5.0-guix0-preview1 with all extensions disabled,
> except "Surfingkeys".
>
> Computer is something like this (neofetch):
[...]
Hm... it seems unlikely that this computer, which is relatively
powerful, couldn
On Wed, Nov 25, 2020 at 11:31:53PM +0100, raingloom wrote:
> Oh yea, regarding that, I really think it would have made a whole lot
> more sense if people just sent in a photo, instead of DDoS-ing the
> network.
I don't know how BBB works nor did I measure it, but one can expect a
videochat feed to
On Thu, Nov 26, 2020 at 12:32:07PM +0100, Jonathan Brielmaier wrote:
> In video conferencing clients need to do video encoding (when they use
> their webcam) as well as video decoding in real time. This can be pretty
> resource hungry (CPU) especially when there is no proper HW acceleration
> by th
On Thu, Nov 26, 2020 at 03:42:02PM +0100, raingloom wrote:
> Since people reported everyone turning their cameras on significantly
> degrading performance, that is unlikely to be an accurate analogy.
> My guess is that it's more similar to watching N simultaneous streams,
> where N is the number of
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
si
On Sat, Dec 05, 2020 at 10:41:50PM +0100, Tobias Geerinckx-Rice wrote:
> I think you misunderstood my (and Ludo's) point, which was to prevent
> possible abuse of a name still in common use. For whatever reason, outside
> of our little echo chamber people say GuixSD, not Guix System. Squatting
>
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 the
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
On Tue, Dec 08, 2020 at 03:13:40PM +0100, zimoun wrote:
> I have missed the discussion on IRC and I do not understand the
> rationale. What's the point of "ungrafting"?
Grafts cause profile operations like `guix install` and `guix
environment` to be slower than without grafts.
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 n
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 will we need to do a
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
unlikely
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?
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 froz
On Mon, Dec 14, 2020 at 11:32:05AM +0100, zimoun wrote:
> But if grafts is here, it is because of something. Therefore, I do not
> understand what it does mean “ungraft”. Avoid the grafting mechanism
> when it is possible?
Grafts are used to "hack" the package dependency graph. We try to make
so
On Mon, Dec 14, 2020 at 03:03:16PM -0500, Mark H Weaver wrote:
> So, it's still a mathematical function (assuming all packages build
> deterministically), but not necessarily the same function as if normal
> upgrades had been done instead of grafts. That's the main issue with
> grafts that I'm awa
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
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-l
On Thu, Dec 24, 2020 at 09:24:17PM -0500, Mark H Weaver wrote:
> What do you think?
I understand your concerns about the ambiguous meaning of an "LTS"
kernel in the context of Guix.
In order to make it more concrete, we could attempt to stay on the same
long-term support kernel series between Gui
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.
On Sun, Dec 27, 2020 at 12:09:05PM -0500, Raghav Gururajan wrote:
> Regardless, your concern is valid. The user might or might not know the
> difference between these forms. For this, I think we add an explanation
> in manual, somewhat like this:
>
> ```
>
> linux-libre => Always points to the la
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
> something I want t
On Wed, Dec 30, 2020 at 04:18:40PM -0500, Raghav Gururajan wrote:
> @Mark or @Leo
>
> > > This guideline, and the code comment in 'gnu/packages/linux.scm', don't
> > > make sense to me.
> > >
> > > All of the kernel packages offered by Guix right now are current LTS
> > > kernels. Do you mean "Al
On Wed, Dec 30, 2020 at 04:18:40PM -0500, Raghav Gururajan wrote:
> From 24fc8ba6ea11a0d45ea8b240292bd56dc865ae52 Mon Sep 17 00:00:00 2001
> From: Raghav Gururajan
> Date: Wed, 30 Dec 2020 16:15:26 -0500
> Subject: [PATCH 11/11] gnu: Revise comment for Linux-Libre-LTS.
>
> * gnu/packages/linux.sc
On Thu, Dec 31, 2020 at 01:09:06PM -0500, Josh Marshall wrote:
> One thing I know that I have run into, and have heard so many times over
> from those on Windows is how unstable or much of a hassle it can be to get
> games to work. In the last few weeks, I spent ~20 hours just to this
> hassle mys
Hi Josh,
I'm replying off-list, because this subject has been discussed s
many times without reaching a different conclusion, and because I worry
about starting a flamewar on the mailing list.
On Thu, Dec 31, 2020 at 02:12:16PM -0500, Josh Marshall wrote:
> So a separate channel would work fo
On Thu, Dec 31, 2020 at 02:12:16PM -0500, Josh Marshall wrote:
> So a separate channel would work for non-free software? I know the stuff
> is fundamentally gross. I'd still like to have a better way to get out of
> an ecosystem that is basically entirely all non-free software and a
> transition
On Thu, Dec 31, 2020 at 02:53:24PM -0500, Leo Famulari wrote:
> Hi Josh,
>
> I'm replying off-list, because this subject has been discussed s
> many times without reaching a different conclusion, and because I worry
> about starting a flamewar on the mailing list.
Oops
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
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.
On Mon, Jan 04, 2021 at 06:02:54PM +0100, Tobias Geerinckx-Rice wrote:
> Leo, does this happen to any guix-patch@ or just Ryan's?
I've been noticing it with Ryan, but I don't know for sure if it happens
with anyone else. Sometimes I remember to change Ryan's address,
sometimes I don't.
signature
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
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
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.
Can you share with us the full error messages you got? And a more full
description of what you tried?
On Thu, Jan 7, 2021, at 20:16, raingloom wrote:
> Hiya folks.
>
> I'm trying to finish up that Snapper package that Pierre Neidhardt
> abandoned and am also running into DBus issues.
> Could som
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
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
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
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
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 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
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
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,
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?
> […]
> >58
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 anyt
On Fri, Jan 15, 2021 at 12:57:50AM -0500, Mark H Weaver wrote:
> Ludovic Courtès writes:
>
> > Following discussions on IRC, I’ve created a new ‘ungrafting’ branch
> > that does nothing but ungraft things.
> >
> > The rationale is that grafts incur additional overhead when installing
> > things (
On Sat, Jan 16, 2021 at 08:51:32PM +0100, Vincent Legoll wrote:
> Hello,
>
> I don't understand the following docstring
> english (even if I guess the meaning):
>
> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system.scm#n861
Indeed, it looks like a typo.
I bet it was rewritten from some
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.
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
On Thu, Jan 21, 2021 at 12:15:28PM +0100, Ludovic Courtès wrote:
> Apologies for not contributing so far, this month is busy for me. I
> think the slow feedback loop with ci.guix is one of the main reasons
> people don’t contribute much. Perhaps the whole process is also unclear
> to people who’r
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
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
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
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:/
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
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
701 - 800 of 3849 matches
Mail list logo
