bug#65665: [PATCH] Really get all the implicit inputs.
Hello Ulf! Ulf Herrman writes: > This patch series causes package-mapping to recurse into package and bag > arguments when #:deep? #t is given. It also recurses into gexps and > gexp inputs in search of packages to devour. It also ensures that build > systems leave all of their implicit package arguments in the bag > arguments, ready to be found by package-mapping. It also fixes a couple > build system errors I came across while modifying 40+ build systems and > testing a deep package transformation. Nice series! I've reviewed it, and it makes sense to me. I'd like to apply it to the core-updates branch. Core team, what say you? -- Thanks, Maxim
bug#66305: Error with recursive git checkout
Hi! Pushed as 762fdbdef52b4c17df578478cadc8655d56171a4. Now to update ‘guix’… Ludo’.
bug#66279: Unexporting
Hi, Maxim Cournoyer skribis: > Ludovic Courtès writes: > >> Hi Maxim, >> >> Commit 03795e2ba27424fc98957da00f6c71325e7ae425 exports the >> record type descriptor (RTD). >> >> Common practice is to keep RTDs private because by publishing them, we >> make it harder to change the ABI (because users might be matching fields >> positionally) and we make it trivial for users to forge records of that >> type, bypassing any checks we may have in the official constructor (such >> as “sanitizers”). > > Perhaps we should document this? More power to the users! Done in commit 7b710836a1c7cb921f54ead64f465bcc5333d076, based on what I wrote above. >> What do you think of reverting this commit? I don’t see references to >> outside of its module. > > I'd like to note there are also valid usages requiring a record type, > such as 'match-record' from (guix records). Otherwise, I don't feel > strongly about it, but if if's done I think the rationale you gave above > should be documented in our contributing guidelines. Alright, done as well in commit 97927608cb4f9c5d721115f1cb638de17ac38e62. Thanks, Ludo’.
bug#60558: (no subject)
Hi, When testing again with x86_64 Guix and Parabola it works fine now. Denis. pgpnRjdwFIn_d.pgp Description: OpenPGP digital signature
bug#66304: [PATCH] gnu: exim: Update to 4.96.1
* gnu/packages/mail.scm (exim): Update to 4.96.1. --- gnu/packages/mail.scm | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/gnu/packages/mail.scm b/gnu/packages/mail.scm index 72d971eb77..e6923627f4 100644 --- a/gnu/packages/mail.scm +++ b/gnu/packages/mail.scm @@ -52,6 +52,7 @@ ;;; Copyright © 2022 jgart ;;; Copyright © 2022 ( ;;; Copyright © 2023 Timo Wilken +;;; Copyright © 2023 Wilko Meyer ;;; ;;; This file is part of GNU Guix. ;;; @@ -1895,7 +1896,7 @@ (define-public msmtp (define-public exim (package (name "exim") -(version "4.96") +(version "4.96.1") (source (origin (method url-fetch) @@ -1909,7 +1910,7 @@ (define-public exim (string-append "https://ftp.exim.org/pub/exim/exim4/old/; file-name (sha256 -(base32 "18ziihkpa23lybm7m2l9wp2farxw0bd5ng7xm9ylgcrfgf95d6i9" +(base32 "0g83cxkq3znh5b3r2a3990qxysw7d2l71jwcxaxzvq8pqdahgb4k" (build-system gnu-build-system) (arguments (list #:phases base-commit: ad5e4fe54a66c725dc03dedebf8e5c65723ccb74 prerequisite-patch-id: 5bde835de1e0f7e9cd752986da0585463713d745 prerequisite-patch-id: cda50d13de497f5c74c87b2def4ae6a7d5807305 prerequisite-patch-id: 7024afc52961b5947429f925c55265f29607c801 prerequisite-patch-id: 10a4f92340880065a5210c983cc878c98c075855 prerequisite-patch-id: e6610085f98fb881bada0bb27b59def23c3d7cc3 -- 2.41.0
bug#66315: bug#66333: [PATCH] gnu: guile-ini: Added missing propagated input (guile-lib).
Fabio Natali skribis: > This should close https://issues.guix.gnu.org/66315. > --- > Hi! > > Just a micro-fix which will hopefully close: > > https://issues.guix.gnu.org/66315 Hi! I tweaked the commit log and applied it, thanks! Ludo’.
bug#66297: guix-daemon not starting after boot
Hi, Sharlatan Hellseher skribis: > After the recent pull and system reconfigure I've started experiencing > guix-daemon not starting up after the system boot. Anything in /var/log/messages? What does ‘herd log’ say? Thanks, Ludo’.
bug#66355: guix_defconfig options cannot be overridden in customize-linux function
Hi Nathan,
Nathan Dehnel writes:
> (let ((linux-package
> (customize-linux
> #:name name
> #:linux linux
> ;; #:configs
> ;;'("CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y"
> ;; "CONFIG_DMA_PERNUMA_CMA=y"
> ;; "CONFIG_FONTS=y"
> ;; "CONFIG_FONT_8x16=y"
> ;; "CONFIG_FONT_SUN12x22=y"
> ;; "CONFIG_FONT_TER16x32=y")
> #:defconfig
> ;; this defconfig contains the config options above (among others)
> (local-file "defconfig-6.6")
>
> #:configs and #:defconfig both cause this error:
>
> Mismatching configurations in .config and
> arch/arm64/configs/guix_defconfig
> (("CONFIG_FRAMEBUFFER_CONSOLE_ROTATION" (#f "y")) ("CONFIG_DM
> A_PERNUMA_CMA" (#f "y")) ("CONFIG_FONTS" (#f "y")) ("CONFIG_FONT_8x16"
> (#f "y")) ("CONFIG_FONT_SUN12x22" (#f "y")) ("CONFIG_FONT_TER16x32
> " (#f "y")))
customize-linux is very limited in that it doesn't resolve the config
inter-dependencies. So if you try to enable CONFIG_FONTS but forget to
also enable any of its required options, you'll end up in the situation
above.
I'd suggest producing a defconfig file with all the correctly resolved
dependencies using the 'make savedefconfig' or similar after modifying
the config with 'make menuconfig'.
Let me know how it goes.
--
Thanks,
Maxim
bug#66345: Invalid hash for rust-trybuild@1.0.19
Hi, Distopico skribis: > On 2023-10-04, Ludovic Courtès wrote: [...] >> It looks like the hash never matched. Distopico, do you happen to have >> a copy with hash 0ab7ahdx563n6kbm14pm3qnxq4fp06pz42nh5ii4acvlzycnwdh4 on >> your disk? If so, could you check how it compares to the one currently >> upstream? >> >> If not, we’ll go ahead and update the hash. >> >> Thanks, >> Ludo’. > > Hi Ludo, thank you for let me know this, Here the patch fixing it, > https://issues.guix.gnu.org/66356 Great, thank you (I assume you didn’t have a copy with the older hash.) Ludo’.
bug#66305: Error with recursive git checkout
Hello, Simon Tournier skribis: > On Wed, 04 Oct 2023 at 18:25, Ludovic Courtès wrote: > >> diff --git a/guix/scripts/perform-download.scm >> b/guix/scripts/perform-download.scm >> index 045dd84ad6..c869f19502 100644 >> --- a/guix/scripts/perform-download.scm >> +++ b/guix/scripts/perform-download.scm >> @@ -108,6 +108,10 @@ (define* (perform-git-download drv output >> (drv-output (assoc-ref (derivation-outputs drv) "out")) >> (algo (derivation-output-hash-algo drv-output)) >> (hash (derivation-output-hash drv-output))) >> + ;; Commands such as 'git submodule' expect Coreutils and sed (among >> + ;; others) to be in $PATH. >> + (setenv "PATH" "/run/current-system/profile/bin:/bin:/usr/bin") >> + >>(git-fetch-with-fallback url commit output >> #:recursive? recursive? >> #:git-command %git > > LGTM. > > Well, I would add a comment explicitly mentioning that’s a temporary fix > pointing this issue #66305. It’s not temporary in that it will still be needed for example by the Debian package of Guix. But yeah, I’ll clarify that in the comment. > And I have tested with: > > $ guix build ocaml-ansiterminal -S --no-substitutes > $ guix build volk --no-substitutes --check -S Awesome, thanks for checking! Ludo’.
bug#66306: Too many services depend on ‘networking’
On Mon, Oct 02, 2023 at 02:24:49PM +0200, Ludovic Courtès wrote: > I believe too many services depend on ‘networking’ for no good reason. > There’s a good discussion of the problem at: > > https://systemd.io/NETWORK_ONLINE/ This exactly! How much 'network' counts as 'good enough' to start the next services? > For example, bitlbee, ntpd, hurd-vm, and avahi-daemon all depend on > ‘networking’. > > Is it always justified? For example, avahi-daemon unconditionally > listens on 0.0.0.0 and [::], so there’s no need to depend on > ‘networking’. > > --8<---cut here---start->8--- > $ sudo netstat -tupla |grep avahi > udp0 0 0.0.0.0:mdns0.0.0.0:* > 650/avahi-daemon: r > udp6 0 0 [::]:mdns [::]:* > 650/avahi-daemon: r > --8<---cut here---end--->8--- > > In other cases, such as bitlbee, it’s not as obvious because users can > specify different addresses to listen to, and those might depend on > ‘networking’ to set up the corresponding interfaces. > > Thoughts? Should we do an audit of these? Probably should do an audit. For bitlbee, I guess the question is how does it respond to changes in networking? If it comes up when only loopback is up will it need to be restarted once an actual network shows up? For ntpd, I've had trouble with openntpd coming up while only loopback was active and then I'd have to restart it for it to get the initial big jump when starting. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
