* gnu/packages/aux-files/emacs/guix-emacs.el
(guix-emacs--subdirs-files): New procedure.
(guix-emacs-load-package-descriptors): Use it.
---
gnu/packages/aux-files/emacs/guix-emacs.el | 33 +-
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git
This fixes a regression introduced with 79cfe30f3 ("build-system: emacs: Use
subdirectories again.") which caused the 'guix-emacs-autoload-packages' to no
longer be able to autoload all packages.
* gnu/packages/aux-files/emacs/guix-emacs.el
(guix-emacs-autoload-packages-called): New variable.
* gnu/packages/aux-files/emacs/guix-emacs.el: Declare LEXCICAL-BINDING file
variable to true.
---
gnu/packages/aux-files/emacs/guix-emacs.el | 1 +
1 file changed, 1 insertion(+)
diff --git a/gnu/packages/aux-files/emacs/guix-emacs.el
b/gnu/packages/aux-files/emacs/guix-emacs.el
index
* gnu/packages/aux-files/emacs/guix-emacs.el: Declare LEXCICAL-BINDING file
variable to true.
---
gnu/packages/aux-files/emacs/guix-emacs.el | 1 +
1 file changed, 1 insertion(+)
diff --git a/gnu/packages/aux-files/emacs/guix-emacs.el
b/gnu/packages/aux-files/emacs/guix-emacs.el
index
Hi,
Since some time, our guix-emacs-autoload-packages in Emacs stopped being
useful at refreshing newly installed packages.
I'll send a proposed change to address this.
--
Thanks,
Maxim
У вт, 2022-05-24 у 10:38 +0300, Roman Riabenko пише:
> The upstream implemented the check for vfat and closed the issue.
> https://gitlab.gnome.org/GNOME/gnome-disk-utility/-/commit/15462f9c87c08c5af77a31993c1d87cb34d04861
>
> (It is not included in Disks version 42.0, so I haven't tested it
>
Hi,
On Saturday, August 26th, 2023 at 22:11, jbra...@dismail.de
wrote:
>
> Shall we go ahead and close this bug report?
I'm okay with that.
> I do not recall a recent time that someone complained about Guix System's
> slow profile generation on hard drives. I currently use guix system on
On 2023-08-27 02:13, 宋文武 wrote:
> Maybe we can automatically report the failures as bugs, say every 7
> days, and remove a package if it still fail to build in 90 days?
Hi, maybe build failures should be limited to certain platforms that can
cause this treatment, such as (32-bit) x86, x86-64 and
Bruno Victal writes:
> On 2023-08-27 02:13, 宋文武 wrote:
>> Maybe we can automatically report the failures as bugs, say every 7
>> days, and remove a package if it still fail to build in 90 days?
maybe precedeed by an automated email notification (to guix-bugs) so
that interested people have the
Since we are at nextcloud@3.8.2 right now, the issue should have disappeared;
closing it.
Thanks for the report and the helpful comments!
Andreas
Hello,
this has most likely been solved by either the new monolithic texlive
package, or the vastly expanded modular texlive. So I am closing the report,
please reopen it if the problem persists.
Thanks for the report,
Andreas
Hello,
has there been any progress on this? Is there a way forward, or should
we close the issue?
Andreas
Closing the bug, as the immediate problem appears to be solved,
and handling of transient network failures is discussed in other issues.
Thanks for your report,
Andreas
Hello,
the monolithic texlive package should not be mixed with additional
texlive packages. With the recent remodelling of the texlive packages,
it would be better to install something like texlive-scheme-medium
instead. Eventually we aim for reaching a metapackage for a full
texlive installation
Hello,
as far as I can tell, this report is not relevant any more to the current
modular texlive build system, so I am closing it.
Please reopen it if anything remains to be addressed.
Andreas
This has probably been solved for a while, closing.
Thanks for the report!
Andreas
Hello,
this bug has probably been addressed by the recent changes to texlive,
so I am closing it. If you still experience problems, please come back
to us, reopen the report or create a new one.
Thanks for your report!
Andreas
Hello, I think the current CI dashboard (eg:
https://ci.guix.gnu.org/eval/693369/dashboard)
is a little inconvenient to use, and I'd like it have:
1. different colors for build failures (status=1) and dependencies
failures (status=2), and other type failures. Maybe yellow for
dependencies
Hi Philip,
Philip Kaludercic writes:
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> ERROR:
> 1. :
> uri: #< scheme: https userinfo: #f host: "ci.guix.gnu.org" port:
> #f path: "/nar/lzip/i4c6yd0n7yhw2qi5217z62zb9n023dk7-automake-1.16.5" query:
> #f fragment: #f>
>
19 matches
Mail list logo
