bug#53547: Error sending email with OpenSMTPD, fatal: time_to_text: bsnprintf
Tobias, I noticed you recently updated opensmtpd to 7.4.0 with commit
5e7f27d6ca7be84453e6d4de3d860b700ba3aef7.
I was curious if you or anyone else has seen this issue, and if I should
try submitting a patch to guix for it.
Timmy Douglas writes:
> I recently installed opensmtpd and have been trying to send email. It
> appears there is an error with the bsnprintf function:
>
> $ ./sendmail -t
> To: timmy
> From: me
> Subject: hi
>
> aoeueou
> (press ^D)
> sendmail: time_to_text: bsnprintf
>
> I reported this issue here:
> https://github.com/OpenSMTPD/OpenSMTPD/issues/1166
>
> mcron appears to invoke sendmail with `-t`, which is how I discovered
> the issue.
>
> If anyone is trying to figure out how to setup the setuid on Guix
> system, here is my config.scm file (I couldn't find anything online so
> maybe this will help):
>
> (operating-system
> ; ...
>(append (list (setuid-program
> (program (file-append opensmtpd "/sbin/smtpctl"))
> (setuid? #f)
> (setgid? #t)
> (user "root")
> (group "smtpq"))
>(setuid-program
> (program (file-append opensmtpd "/sbin/sendmail"))
> (setuid? #f)
> (setgid? #t)
> (user "root")
> (group "smtpq")))
>%setuid-programs))
>
> I tried building the latest opensmtpd from git, which required a few
> other changes to patch the bug:
>
>
>
> diff --git a/usr.sbin/smtpd/smtpc.c b/usr.sbin/smtpd/smtpc.c
> index 49750dca..4ed506dc 100644
> --- a/usr.sbin/smtpd/smtpc.c
> +++ b/usr.sbin/smtpd/smtpc.c
> @@ -114,8 +114,8 @@ parse_tls_options(char *opt)
> servname = value;
> break;
> case -1:
> - if (suboptarg)
> - fatalx("invalid TLS option \"%s\"",
> suboptarg);
> + //if (suboptarg)
> + //fatalx("invalid TLS option \"%s\"",
> suboptarg);
> fatalx("missing TLS option");
> }
> }
> diff --git a/usr.sbin/smtpd/smtpctl.c b/usr.sbin/smtpd/smtpctl.c
> index 00c49cb7..3630ef1d 100644
> --- a/usr.sbin/smtpd/smtpctl.c
> +++ b/usr.sbin/smtpd/smtpctl.c
> @@ -52,6 +52,8 @@
> #endif
> #include
>
> +#include
> +
> #include "smtpd.h"
> #include "parser.h"
> #include "log.h"
> diff --git a/usr.sbin/smtpd/to.c b/usr.sbin/smtpd/to.c
> index 3ea04d89..9928d09b 100644
> --- a/usr.sbin/smtpd/to.c
> +++ b/usr.sbin/smtpd/to.c
> @@ -176,7 +176,7 @@ const char *
> time_to_text(time_t when)
> {
> struct tm *lt;
> - static char buf[40];
> + static char buf[50];
> char *day[] = {"Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"};
> char *month[] = {"Jan","Feb","Mar","Apr","May","Jun",
> "Jul","Aug","Sep","Oct","Nov","Dec"};
> @@ -193,6 +193,9 @@ time_to_text(time_t when)
> #elif defined HAVE_DECL_ALTZONE && defined HAVE_DECL_TIMEZONE
> offset = lt->tm_isdst > 0 ? altzone : timezone;
> tz = lt->tm_isdst > 0 ? tzname[1] : tzname[0];
> +#else
> + offset = 0;
> + tz = "GMT";
> #endif
>
> /* We do not use strftime because it is subject to locale
> substitution*/
bug#65471: home mcron service overwrites PATH with a GuixSD-only directory
Hi Ludovic, Ludovic Courtès writes: […] > I wonder what the preferred behavior would be. Restore PATH to whatever > value it had when the user ‘shepherd’ process was started, at the > expense of making things harder to track/less reproducible? Should we > leave it unset, possibly breaking programs that expect it to be set? > Should we set it to “/run/current-system/profile/bin:/usr/bin” or > similar? 1c30d5a6 was almost 3 months ago, so we could assume most of the users are already reconfigured to this (or newer) commit and fixed their configurations accordingly. Because we probably cannot be sure how they fixed it, I think the best that we could do is not to change the current behavior again and provide a support and documentation if needed, so we don't break users configurations again. Also, the current behavior ‘PATH=/run/current-system/profile/bin’ matches with mcron started by Shepherd on a Guix System on pretty recent commit ‘fc6bdaad57bf91609849623c5f485403c030cb49’, which probably is better than difference of PATH dependending on is it system's Shepherd or user's Shepherd instance running. We could allow users to control an environment of mcron, but I think it should be: - optional for both system's and user's Shepherd instances; - not a default behavior, because we already switched from PATH= to ‘PATH=/run/current-system/profile/bin’. Regards, Oleg. signature.asc Description: PGP signature
bug#67314: xorg-configuration's extra-config should support file-like objects
I needed to tweak some xorg settings (set scroll direction, enable
tearfree, etc). On other distros, this is done by dropping files
of
config snippets into /etc/xorg.conf.d.
On Guix, this needs to be done through the extra-config field of
the
xorg-configuration record. That field requires a list of strings,
which
means the configurations need to be inlined into the config, which
is
verbose and unsightly.
For example:
(operating-system
(services
(append (list (service openssh-service-type)
(set-xorg-configuration
(xorg-configuration
(keyboard-layout keyboard-layout)
(extra-config
(list
"Section \"InputClass\"
Identifier \"Touchpads\"
MatchIsTouchpad \"on\"
Driver \"libinput\"
Option \"ClickMethod\" \"clickfinger\"
Option \"DisableWhileTyping\" \"on\"
Option \"NaturalScrolling\" \"on\"
Option \"Tapping\" \"off\"
EndSection"
The manual states that extra-config takes "a list of strings or
objects," but doesn’t indicate what type of object is expected.
If I
pass a file-like object, like this:
(operating-system
(services
(append (list (service openssh-service-type)
(set-xorg-configuration
(xorg-configuration
(keyboard-layout keyboard-layout)
(extra-config
(list (local-file
"xorg/touchpads.conf")
The resulting Xorg configutation has the store paths for those
files
added to it, instead of their contents. This is an invalid
configuation, rendering Xorg unable to start.
I was able to split the difference by reading the file contents
into the
config, ala:
(set-xorg-configuration
(xorg-configuration
(keyboard-layout keyboard-layout)
(extra-config
(map (lambda (file)
(call-with-port (open-file (string-append "xorg/"
file ".conf") "r") get-string-all))
'("radeon" "elecom-huge" "trackpad")
But this feels like a graceless hack to me.
The situation would be drastically simplified if extra-config
supported
file-like objects.
bug#65471: home mcron service overwrites PATH with a GuixSD-only directory
Hi, Apologies for the delay. nils@landt.email skribis: > when using the home-mcron-service, PATH is set to > /run/current-system/profile/bin . This directory is empty when using guix > home on a foreign distro, meaning all executable paths would need to be > absolute. This includes stuff like /usr/bin/ssh, /usr/bin/nice etc.. > > My guess for the culprit was 1c30d5a6bfc5d48137f4bdcc271189a06fdc6ed3 , which > replaced the custom home-mcron-service-type with mapping it to > mcron-service-type. > The mcron shepherd service in old service type did not mess with the > environment variables, the inherited one does: > #:environment-variables > (cons* "GUILE_AUTO_COMPILE=0" > "PATH=/run/current-system/profile/bin" > (remove (cut string-prefix? "PATH=" <>) > (environ))) As a rule of thumb, I personally always provide absolute file names, as in #~(job … #$(file-append coreutils "/bin/ls") …). I wonder what the preferred behavior would be. Restore PATH to whatever value it had when the user ‘shepherd’ process was started, at the expense of making things harder to track/less reproducible? Should we leave it unset, possibly breaking programs that expect it to be set? Should we set it to “/run/current-system/profile/bin:/usr/bin” or similar? Thanks, Ludo’.
bug#67307: Build of emacs-org-recent-headings and other emacs-org-* packages broken
Hello, Maxim Cournoyer writes: > cuir...@gnu.org (Cuirass) writes: > >> The build emacs-org-recent-headings.i686-linux for specification >> master is broken. You can find the detailed information about this >> build > href="https://ci.guix.gnu.org/build/2603350/details;>here. >> >> https://ci.guix.gnu.org/build/2603350/details > > This package and a few others appear to have broken following an update > to emacs-org [0]. > > [0] https://ci.guix.gnu.org/eval/917321?status=failed Most packages report a missing substitute. Do you understand what is happening? Regards, -- Nicolas Goaziou
bug#67304: Build python-cdflib.x86_64-linux on master is broken.
Hi,
I've open an issue in upstram.
Mean while please check the patch disabling the test.
Thanks,
Oleg
On Mon, 20 Nov 2023 at 22:39, Sharlatan Hellseher wrote:
>
> Hi Guix,
>
> I've checked the cement to the test and it mentioned as a candidate to be
> removed as it's not stable
>
> https://github.com/MAVENSDC/cdflib/blob/master/tests/test_astropy_epochs.py#L116
> # Unfortunately, currently there is a pretty big loss of
> precision that comes with
> # the compute function. Need to stop testing early.
>
> We may consider to disable it to stabilize build.
>
> Thanks,
> Oleg
>
> On Mon, 20 Nov 2023 at 19:25, Eric Bavier wrote:
> >
> > Hi Maxim, thanks for the report.
> >
> > On Mon, 2023-11-20 at 14:02 -0500, Maxim Cournoyer wrote:
> > >
> > > It seems something in the commits series
> > > https://git.savannah.gnu.org/cgit/guix.git/log/?qt=range=2ab5e449246f98b049888dde3c310f5b4a0a64a2..b7abea0fd6a146563830db1dc4ddd0cceb6fcf1c
> > > either broke the test, else it's flaky.
> > >
> >
> > I have built the package locally many times without fail.
> >
> > The failed test is one that checks fidelity of a rountrip time format
> > conversion for a randomly-generated time, so failure may indeed be
> > intermittent.
> >
> > I will try to dig a bit further, and maybe Sharlatan can as well.
> >
> > `~Eric
>
>
>
> --
>
> … наш разум - превосходная объяснительная машина которая способна
> найти смысл почти в чем угодно, истолковать любой феномен, но
> совершенно не в состоянии принять мысль о непредсказуемости.
--
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.
From 2f55a5ac236952ea24d81998da488cff4553c272 Mon Sep 17 00:00:00 2001
Message-ID: <2f55a5ac236952ea24d81998da488cff4553c272.1700520904.git.sharlata...@gmail.com>
From: Sharlatan Hellseher
Date: Mon, 20 Nov 2023 22:52:52 +
Subject: [PATCH] gnu: python-cdflib: Disable shaky test.
* gnu/packages/astronomy.scm (python-cdflib): Disable one test which
causing random build failure.
[arguments]{test-flags}: Add it.
Change-Id: I05ee2feca3bc0f0139fa1a5f00b4fe260b42ec80
---
gnu/packages/astronomy.scm | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/astronomy.scm b/gnu/packages/astronomy.scm
index c063285b52..da15283ef3 100644
--- a/gnu/packages/astronomy.scm
+++ b/gnu/packages/astronomy.scm
@@ -1807,7 +1807,10 @@ (define-public python-cdflib
(base32 "0vpgcbc9pmx0qqfia1frnwq3jkgfp8y3ikqdnzs5bs1sr13p9p3w"
(build-system pyproject-build-system)
(arguments
- (list #:phases
+ ;; Disable shaky test.
+ ;; See https://github.com/MAVENSDC/cdflib/issues/234
+ (list #:test-flags #~(list "-k" "not test_compute_cdfepoch16")
+ #:phases
#~(modify-phases %standard-phases
(add-before 'build 'set-env-version
(lambda _
base-commit: d20ece07dbb09382f361c8bbf0bcab9e83d8b73e
--
2.41.0
bug#67305: Build bffe.x86_64-linux on master is broken.
Maxim Cournoyer writes: > Hi, > > cuir...@gnu.org (Cuirass) writes: > >> The build bffe.x86_64-linux for specification master is >> broken. You can find the detailed information about this build > href="https://ci.guix.gnu.org/build/2664791/details;>here. >> >> https://ci.guix.gnu.org/build/2664791/details > > Seems this new failure was triggered by an upgrade to > guix-build-coordinator. Indeed, but it looks to me to be a design issue/bug with CI covered by #54447: substitute: substitute: updating substitutes from 'http://141.80.167.131'... 0.0% substitute: could not fetch http://141.80.167.131/57337hc8rl2ljilf0xbbjrpiknjwqda7.narinfo 504 substitute: updating substitutes from 'http://141.80.167.131'... 100.0% cannot build missing derivation ‘/gnu/store/57337hc8rl2ljilf0xbbjrpiknjwqda7-bffe-0-2.722c37e.drv’ signature.asc Description: PGP signature
bug#67304: Build python-cdflib.x86_64-linux on master is broken.
Hi Guix, I've checked the cement to the test and it mentioned as a candidate to be removed as it's not stable https://github.com/MAVENSDC/cdflib/blob/master/tests/test_astropy_epochs.py#L116 # Unfortunately, currently there is a pretty big loss of precision that comes with # the compute function. Need to stop testing early. We may consider to disable it to stabilize build. Thanks, Oleg On Mon, 20 Nov 2023 at 19:25, Eric Bavier wrote: > > Hi Maxim, thanks for the report. > > On Mon, 2023-11-20 at 14:02 -0500, Maxim Cournoyer wrote: > > > > It seems something in the commits series > > https://git.savannah.gnu.org/cgit/guix.git/log/?qt=range=2ab5e449246f98b049888dde3c310f5b4a0a64a2..b7abea0fd6a146563830db1dc4ddd0cceb6fcf1c > > either broke the test, else it's flaky. > > > > I have built the package locally many times without fail. > > The failed test is one that checks fidelity of a rountrip time format > conversion for a randomly-generated time, so failure may indeed be > intermittent. > > I will try to dig a bit further, and maybe Sharlatan can as well. > > `~Eric -- … наш разум - превосходная объяснительная машина которая способна найти смысл почти в чем угодно, истолковать любой феномен, но совершенно не в состоянии принять мысль о непредсказуемости.
bug#59365: make-dynamic-linker-cache OOMs for LLVM 15 on i686-linux
Hi, This still happens: --8<---cut here---start->8--- starting phase `make-dynamic-linker-cache' GC Warning: Repeated allocation of very large block (appr. size 16781312): May lead to memory leak and poor performance GC Warning: Repeated allocation of very large block (appr. size 67112960): May lead to memory leak and poor performance GC Warning: Repeated allocation of very large block (appr. size 134221824): May lead to memory leak and poor performance GC Warning: Repeated allocation of very large block (appr. size 67112960): May lead to memory leak and poor performance GC Warning: Repeated allocation of very large block (appr. size 67112960): May lead to memory leak and poor performance GC Warning: Repeated allocation of very large block (appr. size 134221824): May lead to memory leak and poor performance GC Warning: Repeated allocation of very large block (appr. size 134221824): May lead to memory leak and poor performance GC Warning: Repeated allocation of very large block (appr. size 134221824): May lead to memory leak and poor performance GC Warning: Repeated allocation of very large block (appr. size 268439552): May lead to memory leak and poor performance GC Warning: Repeated allocation of very large block (appr. size 33558528): May lead to memory leak and poor performance GC Warning: Repeated allocation of very large block (appr. size 67112960): May lead to memory leak and poor performance GC Warning: Repeated allocation of very large block (appr. size 67112960): May lead to memory leak and poor performance GC Warning: Repeated allocation of very large block (appr. size 268439552): May lead to memory leak and poor performance GC Warning: Repeated allocation of very large block (appr. size 268439552): May lead to memory leak and poor performance GC Warning: Repeated allocation of very large block (appr. size 268439552): May lead to memory leak and poor performance GC Warning: Failed to expand heap by 285216768 bytes GC Warning: Failed to expand heap by 268439552 bytes GC Warning: Out of Memory! Heap size: 3362 MiB. Returning NULL! Warning: Unwind-only out of memory exception; skipping pre-unwind handler. Warning: Unwind-only out of memory exception; skipping pre-unwind handler. Warning: Unwind-only out of memory exception; skipping pre-unwind handler. builder for `/gnu/store/j4w1wrhgpjjcfqf2jskklr95r6hpy51i-llvm-15.0.7.drv' failed with exit code 1 --8<---cut here---end--->8--- See this recent build: https://ci.guix.gnu.org/build/2602334/details -- Thanks, Maxim
bug#67304: Build python-cdflib.x86_64-linux on master is broken.
Hi Maxim, thanks for the report. On Mon, 2023-11-20 at 14:02 -0500, Maxim Cournoyer wrote: > > It seems something in the commits series > https://git.savannah.gnu.org/cgit/guix.git/log/?qt=range=2ab5e449246f98b049888dde3c310f5b4a0a64a2..b7abea0fd6a146563830db1dc4ddd0cceb6fcf1c > either broke the test, else it's flaky. > I have built the package locally many times without fail. The failed test is one that checks fidelity of a rountrip time format conversion for a randomly-generated time, so failure may indeed be intermittent. I will try to dig a bit further, and maybe Sharlatan can as well. `~Eric
bug#67308: Build ffmpeg.i686-linux on master is broken.
Hello, cuir...@gnu.org (Cuirass) writes: > The build ffmpeg.i686-linux for specification master is > broken. You can find the detailed information about this build href="https://ci.guix.gnu.org/build/2602938/details;>here. > > https://ci.guix.gnu.org/build/2602938/details It seems the latest ffmpeg 3.4.13 has a flaky (?) test: --8<---cut here---start->8--- TESTfilter-removegrain-mode-13 --- ./tests/ref/lavf/fits 2023-06-12 09:31:58.0 + +++ tests/data/fate/lavf-fits 2023-11-14 11:46:10.890718571 + @@ -1,9 +1,9 @@ ed9fd697d0d782df6201f6a2db184552 *./tests/data/lavf/graylavf.fits 5328000 ./tests/data/lavf/graylavf.fits -./tests/data/lavf/graylavf.fits CRC=0xbacf446c +./tests/data/lavf/graylavf.fits CRC=0xeb450e41 48e6caf6a59e32f9a8a39979c9183a7f *./tests/data/lavf/gray16belavf.fits 10368000 ./tests/data/lavf/gray16belavf.fits -./tests/data/lavf/gray16belavf.fits CRC=0xae2b58d4 +./tests/data/lavf/gray16belavf.fits CRC=0xcc6d0df7 be2f7112fd193c9a909304c81e662769 *./tests/data/lavf/gbrplavf.fits 15408000 ./tests/data/lavf/gbrplavf.fits ./tests/data/lavf/gbrplavf.fits CRC=0x04ed3828 Test lavf-fits failed. Look at tests/data/fate/lavf-fits.err for details. make: *** [tests/Makefile:225: fate-lavf-fits] Error 1 make: *** Waiting for unfinished jobs TESTfilter-removegrain-mode-14 TESTfilter-removegrain-mode-15 --8<---cut here---end--->8--- -- Thanks, Maxim
bug#67307: Build of emacs-org-recent-headings and other emacs-org-* packages broken
Hello! cuir...@gnu.org (Cuirass) writes: > The build emacs-org-recent-headings.i686-linux for specification > master is broken. You can find the detailed information about this > build href="https://ci.guix.gnu.org/build/2603350/details;>here. > > https://ci.guix.gnu.org/build/2603350/details This package and a few others appear to have broken following an update to emacs-org [0]. [0] https://ci.guix.gnu.org/eval/917321?status=failed -- Thanks, Maxim
bug#67306: Build python-tbb.x86_64-linux on master is broken.
Hi, Maxim Cournoyer writes: > Hello! > > cuir...@gnu.org (Cuirass) writes: > >> The build python-tbb.x86_64-linux for specification master >> is broken. You can find the detailed information about this build > href="https://ci.guix.gnu.org/build/2611592/details;>here. >> >> https://ci.guix.gnu.org/build/2611592/details > > This appears to be resulting from a fix to tbb made in > https://git.savannah.gnu.org/cgit/guix.git/log/?qt=range=66132d6a20b3a8fa4649df338568765540057bd1..7e6580670bc615d89d0216ebddfb6ba81feb0238. It seems julia-static-0.8.3 is also affected by the series: https://ci.guix.gnu.org/build/2610913/details -- Thanks, Maxim
bug#67306: Build python-tbb.x86_64-linux on master is broken.
Hello! cuir...@gnu.org (Cuirass) writes: > The build python-tbb.x86_64-linux for specification master > is broken. You can find the detailed information about this build href="https://ci.guix.gnu.org/build/2611592/details;>here. > > https://ci.guix.gnu.org/build/2611592/details This appears to be resulting from a fix to tbb made in https://git.savannah.gnu.org/cgit/guix.git/log/?qt=range=66132d6a20b3a8fa4649df338568765540057bd1..7e6580670bc615d89d0216ebddfb6ba81feb0238. -- Thanks, Maxim
bug#54447: cuirass: missing derivation error
Hi Ludovic, Ludovic Courtès writes: > Maxim Cournoyer skribis: > >> Another example: https://ci.guix.gnu.org/build/1982454/details >> >> substitute: >> substitute: [Kupdating substitutes from 'http://10.0.0.1'... 0.0% >> substitute: [Kupdating substitutes from 'http://10.0.0.1'... 100.0% >> cannot build missing derivation >> ?/gnu/store/vwhgs9dkj9spryglb180j27dr5vidjxv-ecl-23.9.9.drv? > > This one is from Sep. 9, which is before I deployed the remote-worker > fixes, so I’ll dismiss it (happy to look at more recent ones though!). Here's a more recent occurrence: https://ci.guix.gnu.org/build/2635272/details I haven't restarted it to leave proof of its existence :-) -- Thanks, Maxim
bug#67305: Build bffe.x86_64-linux on master is broken.
Hi, cuir...@gnu.org (Cuirass) writes: > The build bffe.x86_64-linux for specification master is > broken. You can find the detailed information about this build href="https://ci.guix.gnu.org/build/2664791/details;>here. > > https://ci.guix.gnu.org/build/2664791/details Seems this new failure was triggered by an upgrade to guix-build-coordinator. -- Thanks, Maxim
bug#67304: Build python-cdflib.x86_64-linux on master is broken.
Hello! cuir...@gnu.org (Cuirass) writes: > The build python-cdflib.x86_64-linux for specification > master is broken. You can find the detailed information about this > build href="https://ci.guix.gnu.org/build/2635702/details;>here. > > https://ci.guix.gnu.org/build/2635702/details It seems something in the commits series https://git.savannah.gnu.org/cgit/guix.git/log/?qt=range=2ab5e449246f98b049888dde3c310f5b4a0a64a2..b7abea0fd6a146563830db1dc4ddd0cceb6fcf1c either broke the test, else it's flaky. -- Thanks, Maxim
bug#67292: emacs / emacs-transient collisions and bundling
On Mon, 20 Nov 2023 at 13:39, Maxime Devos wrote: > This does not answer how the bundling is not a bug. It answers. Nothing is bundled. It is the official Emacs. > (IIUC, emacs-minimal is for compiling Emacs packages and for scripts, of > which most probably have no need for keyboard-driven menus -- and if > they do have need,) Here, you are speaking about another thing. Please open another bug report for that: is emacs-minimal really minimal? Or could some builtin modes and packages be dropped because they are not required for building Emacs packages? All the best, simon
bug#67292: emacs / emacs-transient collisions and bundling
Bug 2: no collision handling. This is a bug, IMHO. Indeed, if an user prefers another version of builtin modes or packages, they should not collide with the builtin ones. Well, they do not collide when using “guix shell”: guix shell -C emacs emacs-transient -E TERM -- emacs -q Therefore, maybe the issue comes from some specific code from “guix home”. Hum, I do not know. They do, in fact, collide -- as I mentioned in the e-mail you replied to: [...] because "guix shell" (and likewise for "environment") suppresses collision error messages: $ guix shell emacs emacs-transient (see: https://issues.guix.gnu.org/54350). More info: (guix profiles) does not seem to handle this anywhere. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#67292: emacs / emacs-transient collisions and bundling
Op 20-11-2023 om 11:22 schreef Simon Tournier: Hi, On Sun, 19 Nov 2023 at 23:44, Maxime Devos wrote: Bug 1: emacs bundles emacs-transient. (Likewise for quite a few other Emacs packages.) This is not a bug. transient.el is part of Emacs since version 28, see NEWS: --8<---cut here---start->8--- * New Modes and Packages in Emacs 28.1 ** transient.el This library implements support for powerful keyboard-driven menus. Such menus can be used as simple visual command dispatchers. More complex menus take advantage of infix arguments, which are somewhat similar to prefix arguments, but are more flexible and discoverable. --8<---cut here---end--->8--- When an user installs Emacs, they expect to have transient as builtin; it is not bundled. This does not answer how the bundling is not a bug. Unbundling is not incompatible with keeping builtins -- for example, emacs-minimal could be the ‘minimalistic Emacs, without the typical bundled ‘built-in’ stuff’, and emacs could be 'emacs-minimal + the unbundled stuff in propagated-inputs’. (Well, preferably not propagated, but that's just a matter of wrapping or unions etc..) Another option could be to unbundle things in the 'source' of emacs / emacs-minimal and copy over source code from the 'emacs-‘builtin’' packages during a build phase. (IIUC, emacs-minimal is for compiling Emacs packages and for scripts, of which most probably have no need for keyboard-driven menus -- and if they do have need,) I recommend to read the section: * New Modes and Packages in Emacs X in NEWS release files to know which mode or package are included as builtin. I won't -- my package manager is Guix, not Emacs. And yes, these packages are sometimes developed outside the Emacs tree using a dedicated repository, as transient.el or Org-mode for instance. Bug 2: no collision handling. This is a bug, IMHO. Indeed, if an user prefers another version of builtin modes or packages, they should not collide with the builtin ones. Well, they do not collide when using “guix shell”: guix shell -C emacs emacs-transient -E TERM -- emacs -q Therefore, maybe the issue comes from some specific code from “guix home”. Hum, I do not know. They do, in fact, collide -- as I mentioned in the e-mail you replied to: [...] because "guix shell" (and likewise for "environment") suppresses collision error messages: $ guix shell emacs emacs-transient (see: https://issues.guix.gnu.org/54350). Best regards, Maxime Devos OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#48282: CI fails to build opencv on x86-64
It looks like this build failure doesn't happen anymore now. Closing. signature.asc Description: PGP signature
bug#67250: builtin:git-download capability detection not working for the bordeaux build farm
Simon Tournier writes: > Hi Chris, > > On Fri, 17 Nov 2023 at 21:39, Christopher Baines wrote: > >> The bordeaux build farm depends on computing the derivations on one >> machine, then potentially building them on a different machine. >> >> Some of the build machines don't have a new enough guix-daemon that >> understands builtin:git-download, so derivations that use this are >> sometimes failing (e.g. [1]) > > Do you mean that the drv file is generated using a new daemon then this > drv file is “offloaded” to another machine using an older daemon and > thus fails to build it? Roughly, yep. >> One potential approach to address this is somehow have the data service >> indicate that it wants compatible derivations when computing them, >> rather than to have guix do feature detection against the guix-daemon >> that is being used at the point the derivations are being computed. > > Other solutions are: downgrade the daemon of one of the machine or > update the daemon of other machines, no? > > Why would the latter not be possible? It's possible, just difficult. Because with the current guix-daemon, the build coordinator can only build things that can be GC'd, some machines deliberately run older daemons to allow building newer things without hitting this issue. signature.asc Description: PGP signature
bug#67250: builtin:git-download capability detection not working for the bordeaux build farm
Hi Chris, On Fri, 17 Nov 2023 at 21:39, Christopher Baines wrote: > The bordeaux build farm depends on computing the derivations on one > machine, then potentially building them on a different machine. > > Some of the build machines don't have a new enough guix-daemon that > understands builtin:git-download, so derivations that use this are > sometimes failing (e.g. [1]) Do you mean that the drv file is generated using a new daemon then this drv file is “offloaded” to another machine using an older daemon and thus fails to build it? > One potential approach to address this is somehow have the data service > indicate that it wants compatible derivations when computing them, > rather than to have guix do feature detection against the guix-daemon > that is being used at the point the derivations are being computed. Other solutions are: downgrade the daemon of one of the machine or update the daemon of other machines, no? Why would the latter not be possible? Cheers simon
bug#67292: emacs / emacs-transient collisions and bundling
Hi, On Sun, 19 Nov 2023 at 23:44, Maxime Devos wrote: > Bug 1: emacs bundles emacs-transient. > (Likewise for quite a few other Emacs packages.) This is not a bug. transient.el is part of Emacs since version 28, see NEWS: --8<---cut here---start->8--- * New Modes and Packages in Emacs 28.1 ** transient.el This library implements support for powerful keyboard-driven menus. Such menus can be used as simple visual command dispatchers. More complex menus take advantage of infix arguments, which are somewhat similar to prefix arguments, but are more flexible and discoverable. --8<---cut here---end--->8--- When an user installs Emacs, they expect to have transient as builtin; it is not bundled. I recommend to read the section: * New Modes and Packages in Emacs X in NEWS release files to know which mode or package are included as builtin. And yes, these packages are sometimes developed outside the Emacs tree using a dedicated repository, as transient.el or Org-mode for instance. > Bug 2: no collision handling. This is a bug, IMHO. Indeed, if an user prefers another version of builtin modes or packages, they should not collide with the builtin ones. Well, they do not collide when using “guix shell”: guix shell -C emacs emacs-transient -E TERM -- emacs -q Therefore, maybe the issue comes from some specific code from “guix home”. Hum, I do not know. Cheers, simon
