On Sun, Jul 21, 2024 at 09:27:11PM +0200, Kai Jellinghaus wrote:
> Hello, Guix looks awesome. Trying to understand the source & where packages
> are coming from right now/.
> What in the main (if that's the right term for
> https://git.savannah.gnu.org/git/guix.git) repo is necessary to build &
The idea is that it eases development because we don't have to maintain
a versioned API between the core functionality and the packages,
services, etc.
It's similar to how everything is developed together in the Linux kernel.
Also, it encourages people who are developing add-ons to Guix to
For a long time we've not been able to build linux-libre on i686-linux
because the source unpacking process runs out of memory.
I'm forwarding this bug to guix-devel to get more attention.
Is anybody actually using i686-linux anymore? Or should we begin to
officially remove support for it?
For a long time we've not been able to build linux-libre on i686-linux
because the source unpacking process runs out of memory.
I'm forwarding this bug to guix-devel to get more attention.
Is anybody actually using i686-linux anymore? Or should we begin to
officially remove support for it?
On Sun, Jul 21, 2024 at 03:05:53PM +0200, Ludovic Courtès wrote:
> What about adding a new Boost version specifically for use in
> LibreOffice? Eventually that version would become the default one, but
> that can happen later.
>From what I could tell, all of the packages used by Libreoffice that
On Thu, Jul 11, 2024 at 04:23:09PM -0400, Leo Famulari wrote:
> Subject: [PATCH] WIP: Boost: Fix a bug that breaks libetonyek.
>
> This fixes <https://issues.guix.gnu.org/72040>
>
> * gnu/packages/patches/boost-fix-duplicate-definitions-bug.patch: New file.
> * gnu/l
Thank you Ricardo! I was totally stuck on this.
On Mon, Jul 22, 2024, at 05:29, Ricardo Wurmus wrote:
> This is now fixed in commit bdff6baca39a73b3cfc5400e117795cad0c180cf.
>
> dbus-daemon watches XDG_* directories, and it bailed out because the
> list of directories to watch is just too large.
On Wed, Jul 17, 2024 at 09:21:53PM +, jgart wrote:
> > I'm not sure I understand the question. Gunicorn-next contains the CVE
> >
> > fix, but gunicorn does not? Is that correct?
>
> Yep, that is correct. gunicorn does not contain the fix and gunicorn-next
> does contain the fix.
Okay. Is
On Mon, Jul 15, 2024 at 07:38:11PM -0400, Leo Famulari wrote:
> It's weird that dbus is killed by signal 11, SIGSEGV.
>
> I see that some other package manually start dbus for the test suite, so
> I'll try my hand at it.
Hm, I didn't make any progress with this. Does anyone have a
On Wed, Jul 17, 2024 at 04:08:34AM +, jgart wrote:
> I provided gunicorn-next in a recent commit to master which fixes
> CVE-2024-1135 but I don't have time at the moment to fix the bad gunicorn's
> dependents* against gunicorn-next.
I'm not sure I understand the question. Gunicorn-next
On Sun, Jul 14, 2024 at 01:52:37PM -0400, Leo Famulari wrote:
> I reported this problem upstream:
>
> https://gitlab.gnome.org/GNOME/epiphany/-/issues/2392
The GNOME team suggests that we make sure that dbus is running in the
build environment, and indeed it seems there is someth
I reported this problem upstream:
https://gitlab.gnome.org/GNOME/epiphany/-/issues/2392
For some reason, mumi doesn't display the message
I sent about this bug, but only the attachment. It does display on
. In any case, here is the original message:
On core-updates commit 378e1d9b69b030, Epiphany (the GNOME web browser)
fails its test suite. Specifically, several of its tests fail
I was holding it wrong. icu4c-73 and icecat are fine on core-updates.
Sorry for the noise!
On core-updates commit dd9660264b39b. the icu4c-73 package fails its
tests like this:
--
make[2]: Leaving directory
'/tmp/guix-build-icu4c-73.1.drv-0/icu/source/test/cintltst'
-
| *** FAILING TEST SUMMARY FOR: intltest
On Sat, Jul 13, 2024 at 01:39:21PM -0400, Leo Famulari wrote:
> There is some discussion on the Libreoffice mailing list, but so far
> it's inconclusive from my perspective. But if I understand correctly,
> their recommended solution would be to create a source origin of
> Boost
On Thu, Jul 11, 2024 at 04:23:09PM -0400, Leo Famulari wrote:
> Here's a patch that patches Boost, while also creating a hidden package
> boost-for-source-highlight. This variant is only used by the
> source-highlight package, which is used by gdb, and thus rust. So, it
> aims to avoi
Julien Nabet wrote:
> Could you provide the autogen.input you use?
>
> I'm on Debian testing which uses Boost 1.83 but when checking
> config.log, I see:
>
> configure:33360: checking which boost to use
> configure:34711: result: internal
>
> and internal Boost used is 1.85 version.
Where can
On Fri, Jul 12, 2024 at 04:53:23PM +1000, Christoph Willing wrote:
> > If your distro still somehow manages to provide libetonyek, you might
> > try to build with autogen option `--with-system-libetonyek` as a
> > workaround.
>
> Hi Leo,
>
> Your build of libetonyek will succeed if you fully
On Thu, Jul 11, 2024, at 11:32, Leo Famulari wrote:
> On Thu, Jul 11, 2024 at 11:25:34PM +0800, Zheng Junjie wrote:
>> > So, it's a problem with cmake?
>> >
>> > Do you know if they've fixed it in later versions?
>>
>> see https://gitlab.kitware
As reported on the Document Foundation bug tracker, Boost >= 1.81 breaks
compilation of libetonyek:
https://bugs.documentfoundation.org/show_bug.cgi?id=152569
I confirm the problem persists with Boost 1.83.0.
There are bunch of duplicate symbol errors like this (full log attached):
--
On Thu, Jul 11, 2024 at 03:15:27PM -0400, Leo Famulari wrote:
> I'm testing a patch for Boost now. It will cause a huge number of
> rebuilds, so it would be great to come up with another approach.
Here's a patch that patches Boost, while also creating a hidden package
boost-for-source-hig
On Mon, Jun 17, 2024 at 11:30:37PM +0200, Ludovic Courtès wrote:
> 1. Checking whether your favorite packages build and work.
Libreoffice is blocked on core-updates, due a build failure of
libetonyek, caused by a bug in Boost:
https://issues.guix.gnu.org/72040
I think that Libreoffice is
I found the bug report, which is for Boost:
https://github.com/boostorg/phoenix/issues/111
Basically, versions 1.81 through 1.83 exhibit this defect.
I'm testing a patch for Boost now. It will cause a huge number of
rebuilds, so it would be great to come up with another approach.
On Thu, Jul 11, 2024 at 12:00:56PM -0400, Leo Famulari wrote:
> I think this upstream report (closed without resolution) describes the
> problem:
>
> https://bugs.documentfoundation.org/show_bug.cgi?id=152569
I sent a report to the mailing list where build failures are supposed to
I think this upstream report (closed without resolution) describes the
problem:
https://bugs.documentfoundation.org/show_bug.cgi?id=152569
Boost 1.81 (and presumably 1.83, which we have on core-updates) is not
compatible with the libetonyek code.
On Thu, Jul 11, 2024 at 11:32:53AM -0400, Leo Famulari wrote:
> Okay, great. I confirm your patch fixes the problem. I'll push it to
> core-updates on your behalf.
Pushed as 50243774824597dbd141a074a7be0117dc450cef
Thanks for your help!
signature.asc
Description: PGP signature
On Thu, Jul 11, 2024 at 11:25:34PM +0800, Zheng Junjie wrote:
> > So, it's a problem with cmake?
> >
> > Do you know if they've fixed it in later versions?
>
> see https://gitlab.kitware.com/cmake/cmake/-/issues/25200
Thanks!
> > Would this remove zlib support from openimageio?
>
> no, just
On Thu, Jul 11, 2024 at 02:29:59PM +0800, Zheng Junjie wrote:
> see patch, as i known, because ours cmake too old, have a bug about zlib.
So, it's a problem with cmake?
Do you know if they've fixed it in later versions?
> + #:phases #~(modify-phases %standard-phases
> +
On core-updates commit 378e1d9b69b030, Epiphany (the GNOME web browser)
fails its test suite. Specifically, several of its tests fail like this:
--
>>> G_TEST_BUILDDIR=/tmp/guix-build-epiphany-44.8.drv-0/build/tests
>>> GSETTINGS_SCHEMA_DIR=/tmp/guix-build-epiphany-44.8.drv-0/build/data
>>>
On core-updates commit 378e1d9b69b030a165, openimageio fails to build
like this:
--
[ 30%] Building CXX object
src/libOpenImageIO/CMakeFiles/OpenImageIO.dir/imageio.cpp.o
cd /tmp/guix-build-openimageio-2.5.13.0.drv-0/build/src/libOpenImageIO &&
On core-updates commit 378e1d9b69b030a, python-gst fails its test suite
like this:
--
==
FAIL: testPropertyMarshalling (test_types.TestFraction)
--
Traceback
On Thu, Jul 11, 2024 at 02:00:45AM +0800, Zheng Junjie wrote:
> i think just disable this test, see
>
> https://invent.kde.org/frameworks/ki18n/-/commit/241e0cfa96b1491721f361f1713b3514c58bde56#note_654140
>
On core-updates commit 736939037346, libetonyek fails to build like
this (sorry in advance for the long lines, full log attached):
--
CXXLDlibetonyek-0.1.la
On core-updates commit 736939037346, ki18n fails its test suite like
this:
* Start testing of KCatalogTest *
Config: Using QtTest library 5.15.10, Qt 5.15.10 (x86_64-little_endian-lp64
shared (dynamic) release build; by GCC 11.4.0), unknown unknown
PASS :
I messed up this report so I'm closing it and will open a new one. I
think it will be too confusing to leave this report open as it is.
On core-updates commit 736939037346, libetonyek fails its test suite
like this:
--
* Start testing of KCatalogTest *
Config: Using QtTest library 5.15.10, Qt 5.15.10 (x86_64-little_endian-lp64
shared (dynamic) release build; by GCC 11.4.0), unknown unknown
PASS :
On Mon, Jun 17, 2024 at 11:30:37PM +0200, Ludovic Courtès wrote:
> You can help settle this branch by:
>
> 1. Checking whether your favorite packages build and work.
I reconfigured my x86_64 headless system on commit 7369390373464e1
(currently the latest commit), and it seems to be working
On Sun, Jun 23, 2024 at 10:39:18AM +0200, Liliana Marie Prikler wrote:
> Note: Security bugs should go to guix-security instead. But thanks for
> pointing out the new Emacs release, I've pushed an update. (Thus
> marking this done)
I think that only secret security bugs should go to
On Tue, Jun 25, 2024 at 01:56:44PM -0700, Felix Lechner via Development of GNU
Guix and the GNU System distribution. wrote:
> Today I received this private message:
>
> "hey, as i said before, your bot "peanuts" is fucking
> annoying. it floods the channel too much. the only feature i
On Mon, Jun 10, 2024 at 08:30:32AM +, Guillaume Le Vaillant wrote:
> On an IPv6-only network, the default configuration for ntp-service-type
> doesn't work, because the default pool used (<0.guix.pool.ntp.org>)
> doesn't have IPv6 addresses.
>
> In fact, the <1.guix.pool.ntp.org> and
On Tue, Jun 04, 2024 at 01:05:39PM +0200, Nils Landt wrote:
> I built a home service for systemd. It is currently unpublished, but I could
> demo it, and publish the WIP version.
>
> Not sure if there's enough interest in this to warrant a talk, systemd is not
> packaged for Guix (and quite
On Tue, Jun 04, 2024 at 01:05:39PM +0200, Nils Landt wrote:
> I built a home service for systemd. It is currently unpublished, but I could
> demo it, and publish the WIP version.
>
> Not sure if there's enough interest in this to warrant a talk, systemd is not
> packaged for Guix (and quite
On Wed, Jun 05, 2024 at 09:00:59PM +, Kaelyn wrote:
> As a ZFS user, I'd like to offer a bit of clarification: zfs-auto-snapshot
> doesn't depend on any specific kernel versions, but zfs itself does. For
> example, zfs 2.2.3 supports up to kernel 6.7, and zfs 2.2.4 supports up to
> kernel
On Tue, Jun 04, 2024 at 08:41:47AM +0200, Ludovic Courtès wrote:
> It seems that it broke ‘x86-energy-perf-policy’ and ‘zfs-auto-snapshot’:
>
> https://ci.guix.gnu.org/eval/1374635?status=newly-failed
Aha, a new feature in the CI web interface! Wonderful!
The failure of
>From a computational perspective, downloading tarballs is much simpler than
>fetching from Git.
But Git offers so many advantages, and computing has become so inexpensive,
that it's become very common to use Git instead.
Recent Git implementations have optimized serving of specific Git
On Sat, Apr 13, 2024 at 12:32:45PM +0200, Simon Tournier wrote:
> So I propose to add the plumbing command ’derivation’. Any objection?
Sounds good to me, but give it a couple days for everyone else to ponder
the bike shed ;)
On Thu, Apr 11, 2024 at 03:18:49PM -0400, Leo Famulari wrote:
> I sent a patch:
>
> https://issues.guix.gnu.org/issue/70343
This should be fixed with commit cc38699cf0cfd804a43ca1b6c8602cfc84e06117
Please let us know if you see more problems. Thanks for the report!
On Fri, Apr 12, 2024 at 08:28:11PM +0200, Simon Tournier wrote:
> Therefore, I wrote a very simple Guix extension [1] that outputs
> derivation content using recutils format.
Amazing! That's so useful.
> Do you think it would be useful to package it? Or maybe to include it
> as another
On Thu, Apr 11, 2024 at 10:55:39AM -0400, Leo Famulari wrote:
> Okay, thanks for looking. We can add a dependency on python-pyyaml and
> it should work.
I sent a patch:
https://issues.guix.gnu.org/issue/70343
And CI will test it here:
https://ci.guix.gnu.org/eval/1241100
On Thu, Apr 11, 2024 at 04:42:27PM +0200, Tomas Volf wrote:
> I would assume it is the texinfodocs triggering the YNL_INDEX for us. This
> snippet from the commit message:
>
> If one of other targets such as latexdocs or epubdocs is built
> without building htmldocs, missing .rst files can
On Wed, Apr 10, 2024 at 05:05:15PM +0200, Tomas Volf wrote:
> linux-libre-documentation is broken again:
>
> starting phase `build'
> Traceback (most recent call last):
> File
> "/tmp/guix-build-linux-libre-documentation-6.8.4.drv-0/linux-6.8.4/./tools/net/ynl/ynl-gen-rst.py",
>
I just saw this on Debian:
--
$ guix shell -D guix -- ./pre-inst-env guix weather linux-libre
computing 1 package derivations for x86_64-linux...
looking for 1 store items on https://ci.guix.gnu.org...
guix weather: warning: substitutes from 'https://ci.guix.gnu.org' are
unauthorized
hint:
On Mon, Apr 01, 2024 at 09:46:12PM +0200, Reza Housseini wrote:
> Just stumbled upon this recently discovered supply chain attack on xz,
> inserting a backdoor via test files [1, 2]. And it made me wondering, what
> would have been the effects on guix and how can we potentially avoid it?
There's
On Sun, Mar 17, 2024 at 09:39:12AM -0700, Zacchaeus Scheffer wrote:
> Hi all,
>
> I know this isn't a properly submitted patch, but I think the change is
> pretty simple. 2024 taxes are comming up in the US. Could someone bump
> the version number for opentaxsolver? I tested the following
On Thu, Feb 29, 2024, at 02:11, Efraim Flashner wrote:
> * Most of the packages in rust-apps have been upgraded.
> * rav1e was upgraded from 0.6.6 to 0.7.1
> * dav1d was upgraded from 1.0.0 to 1.3.0
> * libaom was upgraded from 3.5.0 to 3.8.0
Thanks for updating these AV1 video packages!
Can you share the error messages here?
On Thu, Feb 22, 2024, at 09:13, Gabriel Wicki wrote:
> linux-libre-documentation fails to build (see
> https://ci.guix.gnu.org/build/3512631/details)
Pushed as 877abbdae790deaacf30af8a845e2290c39e10ff
On Fri, Feb 09, 2024 at 09:28:14PM +0100, Wilko Meyer wrote:
> * gnu/packages/aux-files/linux-libre/6.7-arm.conf,
> gnu/packages/aux-files/linux-libre/6.7-arm64.conf: Add platform support.
Thanks! Pushed to 'kernel-updates' along with the latest releases.
On Thu, Feb 08, 2024 at 07:57:38AM +0100, Wilko Meyer wrote:
> Vagrant Cascadian writes:
>
> > [[PGP Signed Part:Undecided]]
> > The linux-libre 6.7.x package contains ... as far as I can tell, no
> > supported arm64/aarch64 platforms! This is a pretty significant
> > regression from the
On Mon, Feb 5, 2024, at 04:39, Steve George wrote:
> Our goal for the discussion:
>
> How do we double the number of patches that are *reviewed* and
> *applied* to Guix in the next six months?
>
> Patch flow is a pipeline, to change it we could:
>
> a. Increase the number of committers
After 4 years, many upstream releases of mpv and FFmpeg, and a new
laptop, I'm closing this bug as "not actionable".
On Tue, Jan 09, 2024 at 11:19:51PM -0500, Maxim Cournoyer wrote:
> Hello Guix!
>
> I'm happy to start the 2024 year with a new committer onboard: Sharlatan
> (Oleg).
>
> Sharlatan is maintaining a growing collection of astronomy packages in
> Guix, among others.
>
> Let's Wish them a warm
97cf2dfde536e33c9329bf865c32c05c77caa81b
Author: Leo Famulari
AuthorDate: Wed Dec 20 18:27:18 2023 -0500
.guix-authorizations: Update lfam's key.
* .guix-authorizations: Update lfam's signing key fingerprint.
---
.guix-authorizations | 3 +--
1 file changed, 1 insertion(+), 2
312197ca9068a46ac9a1ea6c40dc03a41cf6110c
Author: Leo Famulari
AuthorDate: Wed Dec 20 18:25:47 2023 -0500
Add lfam's new key.
* lfam-BACA7F08.key: Rename to ...
* lfam (old)-BACA7F08.key: ... this
* lfam-757F47FF.key: New file.
---
lfam-BACA7F08.key => lfam (old)-BACA7F08.key | 0
l
b22555c98e2f2f911a61c1babdf883887c386065
Author: Leo Famulari
AuthorDate: Wed Dec 20 13:35:57 2023 -0500
website: security: Update Leo's key.
* website/apps/base/templates/security.scm (security-t): Update key
fingerprint.
---
website/apps/base/templates/security.scm | 2 +-
1 file
On Fri, Dec 15, 2023 at 06:06:26AM +, John Kehayias wrote:
> I suppose I should have been more specific than "something bad" :) I
> merely meant this wasn't an actual security issue of losing control of
> a private key, but merely moving to a new one for other reasons.
The old key "expired"
On Wed, Dec 13, 2023, at 22:17, John Kehayias wrote:
> And I assume all this was just to use a new key (did I see some
> mention of subkeys on #guix? that's what I use) and not because of
> something bad happening to the old one right?
I don't know if anything bad happened to the old key. That's
On Tue, Dec 12, 2023 at 12:02:33PM -0500, Maxim Cournoyer wrote:
> Note that I believe you can simply update to your new key yourself.
> You'll want to add your new key to the keyring branch, then adjust the
> .guix-authorizations file with its new keygrip.
Thanks, I pushed to 'keyring' as
Hello,
I'm changing my Guix signing key from
B0515948F1E7D3C1B98038A02646FA30BACA7F08 to
68407224D3A64EE53EAC6AAC1963757F47FF.
Patches to follow. Testing is appreciated!
Leo
signature.asc
Description: PGP signature
On Mon, Dec 11, 2023 at 11:30:10AM +0800, Hilton Chain wrote:
> On Mon, 11 Dec 2023 08:13:58 +0800,
> Leo Famulari wrote:
> >
> > Everyone with commit privileges should feel free to push these patches to
> > master if they seem okay. I won't be able to help today.
&g
Everyone with commit privileges should feel free to push these patches to
master if they seem okay. I won't be able to help today.
Leo
On Sun, Dec 10, 2023, at 00:35, Hilton Chain wrote:
> Hi Felix (and Leo, Cc-ed)
>
> On Sun, 10 Dec 2023 11:00:47 +0800,
> Felix Lechner via Development of GNU
As reported on #guix by jeremyc [0], the standard method for calculating
the hash of a Git checkout is not working as expected for the Erlang
package [1].
Currently, our Erlang package has this source block:
--
(version "25.3.2")
(source (origin
(method git-fetch)
I see that ci.guix.gnu.org's builders seem to run out of memory while
building kernel headers for i686-linux:
--
xz: (stdin): Cannot allocate memory
/gnu/store/ns71xxkb3fzr37934bim9l8xiv68kc7w-tar-1.34/bin/tar:
/gnu/store/536ifp75wv8i1kb1k0szv7zd57ygpg0n-linux-libre-6.5.13-guix.tar.xz:
On Mon, Nov 27, 2023, at 01:53, Andy Tai wrote:
> Hi, hope Guix maintainers can clarify the role of the now core-updates
> branch; the current documentation does not specify the core-updates
> branch as a thing but there are clearly interests and uses of this
> branch for package updates not
On Wed, Nov 22, 2023 at 07:16:21PM +0100, Ludovic Courtès wrote:
> Leo, Tobias, and John: What would be a good end-of-term date for each
> one of you? As I see it, it wouldn’t mean you cannot do an additional
> term but rather that you’ll have an opportunity to leave and that you’ll
> do your
On Tue, Nov 14, 2023 at 12:11:14AM -0500, Leo Famulari wrote:
> On Tue, Oct 31, 2023 at 01:29:00AM +0100, Wilko Meyer wrote:
> > * gnu/packages/linux.scm (linux-libre-6.6-version,
> > linux-libre-6.6-gnu-revision,
> > deblob-scripts-6.6, linux-libre-6.6-pristine-source, l
On Tue, Oct 31, 2023 at 01:29:00AM +0100, Wilko Meyer wrote:
> * gnu/packages/linux.scm (linux-libre-6.6-version,
> linux-libre-6.6-gnu-revision,
> deblob-scripts-6.6, linux-libre-6.6-pristine-source, linux-libre-6.5-source,
> linux-libre-headers-6.6, linux-libre-6.6): New variables.
> *
On Thu, Nov 09, 2023 at 03:57:36PM +0100, Wilko Meyer wrote:
> * gnu/packages/linux.scm (linux-libre-6.6-version,
> linux-libre-6.6-gnu-revision,
> deblob-scripts-6.6, linux-libre-6.6-pristine-source, linux-libre-6.5-source,
> linux-libre-headers-6.6, linux-libre-6.6): New variables.
> *
On Mon, Nov 06, 2023 at 11:41:47PM +0100, Wilko Meyer wrote:
> Agreed, thanks for mentioning this! I'll send a v3 of this patch series
> that splits up the changes in two commits; one introducing 6.6, the
> other making it the default kernel (which can be applied after a couple
> of days if 6.6
On Wed, Nov 01, 2023 at 03:32:27PM +0100, Wilko Meyer wrote:
> * gnu/packages/linux.scm (linux-libre-6.6-version,
> linux-libre-6.6-gnu-revision,
> deblob-scripts-6.6, linux-libre-6.6-pristine-source, linux-libre-6.5-source,
> linux-libre-headers-6.6, linux-libre-6.6): New variables.
> *
On Wed, Nov 01, 2023 at 03:32:27PM +0100, Wilko Meyer wrote:
> * gnu/packages/linux.scm (linux-libre-6.6-version,
> linux-libre-6.6-gnu-revision,
> deblob-scripts-6.6, linux-libre-6.6-pristine-source, linux-libre-6.5-source,
> linux-libre-headers-6.6, linux-libre-6.6): New variables.
> *
On Mon, Oct 30, 2023 at 11:26:55PM +0100, Wilko Meyer wrote:
> * gnu/packages/linux.scm (deblob-scripts 5.10): Update hash.
Pushed as e3f318f0489322c4c9b5964f03a8b063a7bfbebd, thanks!
On Mon, Oct 30, 2023 at 11:26:51PM +0100, Wilko Meyer wrote:
> Wilko Meyer (4):
> gnu: deblob-scripts 6.5: Update hash.
> gnu: deblob-scripts 6.1: Update hash.
> gnu: deblob-scripts 5.15: Update hash.
> gnu: deblob-scripts 5.10: Update hash.
Thanks! I pushed patches 2 through 4 to
Hello everyone,
It seems that linux-libre 6.6 will be released soon.
Would anyone like to try their hand at packaging it for Guix? Wilko, do
you feel up to it?
As I mentioned previously, this requires a bit more work than minor
kernel upgrades because the kernel configs need to be updated.
I'm
On Thu, Oct 12, 2023 at 02:15:41PM +0200, Wilko Meyer wrote:
> seems to be good again at least, as in:
>
> - it builds locally
> - QA[1] looks okayish as far as I can tell (no lint warnings, build
> statuses look good on more common ISA)
I agree, this already counts as "good".
I pushed your
On Mon, Oct 9, 2023, at 12:21, Wilko Meyer wrote:
> I've seen the recent thread on making linux-libre
> 6.5 the default kernel[0] and will have some time at hand later on
> today. I could try to prepare a patch set doing this to get more
> familiar with the process, which would then need a review.
On Mon, Oct 9, 2023, at 03:20, Ada Stevenson wrote:
> So, to make things clear, the delay in making 6.5 the default kernel is
> in part because you lack sufficient support in the case that things go
> wrong or some urgent change needs to be pushed?
There's almost never anything wrong, but I
On Tue, Oct 03, 2023 at 11:05:40AM +, Ada Stevenson wrote:
> Hi Guix!
Hi!
> I understand why that may be; the commit is quite new, and pushing new
> kernel versions on everyone is a pretty big thing. I just want to know what
> the timeline on this sort of thing is - when can we expect the
On Sat, Oct 07, 2023 at 08:31:58PM +0200, Wilko Meyer wrote:
> I could imagine myself helping with these tasks. Practically this means,
> that, whenever a new linux-libre minor update is being released, the
> versions in linux-libre-* packages in gnu/packages/linux.scm have to be
> bumped/a patch
Hello,
For a few years, I've been handling updates of the linux-libre kernel by
myself. Now I want some more people to help with this.
The work itself is fairly mechanical and updates occur about once a
week. It takes about 30 minutes to prepare the patches and push them to
CI or send them to
Fixed with commit 8b8607a9452b7690b15f7db2613abdc211d40cee
I see, thanks for the explanation!
On Mon, Aug 28, 2023, at 18:40, Maxim Cournoyer wrote:
> tags 65585 + notabug
> quit
>
> Hi Leo,
>
> Leo Famulari writes:
>
>> With a `guix describe` like this, I'm unable to build Guix from a fresh Git
>> checkout of the master
With a `guix describe` like this, I'm unable to build Guix from a fresh Git
checkout of the master branch.
--
guix 985638a
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 985638aea14720e16ed5fd94a0e1382a57dec7ac
--
--
$ guix shell
The update of rxvt-unicode to version 9.31 brought a bug that causes the
prompt in new terminal instances to be placed in the middle of the
window and not at the top.
Reported upstream:
http://lists.schmorp.de/pipermail/rxvt-unicode/2023q1/002639.html
Also reported at Arch with a patch to fix
I noticed this inconsistency:
--
$ ls -l /var/log/messages*
-rw-r- 1 root root 112994 Jul 10 14:29 /var/log/messages
-rw-r--r-- 1 root root 8883 Jul 5 12:00 /var/log/messages.1.gz
--
This seems like a mistake.
On Sun, Jun 11, 2023 at 09:43:52PM -0400, Maxim Cournoyer wrote:
> Donating hardware is a bit tricky because it needs to be hosted
> somewhere, but it can be discussed and welcome, especially if the
> hosting can also be provided somehow (we have a couple machines running
> in people's home
On Sun, Jun 11, 2023 at 08:47:54PM -0400, Maxim Cournoyer wrote:
> I'm not sure how that'd work, since Git only allows a single PGP
> signature per commit, as far as I can tell. When you rewrite the
> history (by using rebase, say), the existing signatures of the rewritten
> (rebased) commits are
On Fri, May 19, 2023 at 11:34:35AM +0200, Josselin Poiret wrote:
> I'm curious Leo, in general (not Guix because we have a pre-push hook),
> how do you make sure you always publish signed commits? I don't want to
> put unsigned commits anywhere except locally, but it feels like I might
> just
On Wed, Mar 15, 2023 at 10:02:20PM -0400, Maxim Cournoyer wrote:
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Throw to key `guile-ssh-error' with args `("write_to_channel_port"
> "Parent session is not connected" # 7fca183c31c0> #f)'.
> --8<---cut
1 - 100 of 9672 matches
Mail list logo
