On Tue, Feb 02, 2021 at 06:35:14PM +0100, Nicolò Balzarotti wrote:
> Bengt Richter writes:
>
> > Hi Yasu,
> >
> > "Just curious", what do you hope will be the effect of your post?
> >
> Hi Bengt Richter, thanks for asking the same things I had in mind. This
> post seems just M$ propaganda, more
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:
On Mon, Feb 01, 2021 at 04:57:58PM +0100, Pjotr Prins wrote:
> So far, we'll have a GNU Hurd session and a Rust packaging session. We
> will also discuss ARM, RISC-V and GNU Mes. Otherwise the program is
> open for newbies and unconference topics alike. If you want to propose
> something this may
On Mon, Feb 01, 2021 at 08:43:19PM +, Christopher Baines wrote:
> > Efraim Flashner writes:
> >
> >> On Mon, Feb 01, 2021 at 12:14:03PM +0100, Hartmut Goebel wrote:
> >>> Hi,
> >>>
> >>> maybe the process should be the other way round:
> >>>
> >>> staging -> "staging-frozen" -> master
> >>>
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
>
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:
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
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.
> new 4ecc2a2
On January 19 2021, we received a message from Maxime Devos describing a
potential attack vector on Guix System.
If an attacker can exploit a remote code execution vulnerability (RCE)
in a program used by a Guix service, they could use it to take over the
system in some cases. We have not
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
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
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
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 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'):
>
>
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 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 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
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 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 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
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 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 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 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
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
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:
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
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',
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
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.
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
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
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
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
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
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.
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 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
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, I f
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
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
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
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.
>
> *
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
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
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
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 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
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 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
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
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
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
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 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
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
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 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 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 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
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
>
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
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
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
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
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,
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 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
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 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: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,
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
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 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:
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
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,
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 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
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
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 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
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 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
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
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
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 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, it's
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
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
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
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 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
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
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 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
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 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.
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 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
301 - 400 of 3568 matches
Mail list logo
