bug#51258: [PATCH v3] gnu: emacs: Handle pdump filenames that contain a fingerprint
From: Morgan Smith * gnu/packages/emacs.scm (emacs) [restore-emacs-pdmp]: Change regex to handle filenames that have a fingerprint in them. Remove #t at the end of the phase. Don't bother deleting the old files because rename will overwrite them anyways. --- find-files does sort its return so my previous 2 patches probably work great regardless of the number of pdmps we encounter (which will only ever be 1 anyways). Also the fingerprint is a 32 char hexidecimal number used to uniquely[1] identify the Emacs binary (well more specifically an earlier binary generated during the build process). If you put the version in there it would completely invalidate the entire purpose of this fingerprint. Different distros will have different fingerprints for the same version and that's the point. Here is another over engineered solution even though the previous 2 still work great. I'm not sure if I'm supposed to just throw a '(use-modules ...)' in the phase but if we want to use the #:modules argument then it will break all of the other Emacsen that inherit from Emacs since they use different build systems. 1. Hash collisions are a thing so maybe not actually uniquely gnu/packages/emacs.scm | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm index 6d9950d068..e25b79b832 100644 --- a/gnu/packages/emacs.scm +++ b/gnu/packages/emacs.scm @@ -179,18 +179,18 @@ (define* (emacs-byte-compile-directory dir) (add-after 'glib-or-gtk-wrap 'restore-emacs-pdmp ;; restore the dump file that Emacs installs somewhere in ;; libexec/ to its original state - (lambda* (#:key outputs target #:allow-other-keys) - (let* ((libexec (string-append (assoc-ref outputs "out") + (lambda* (#:key outputs #:allow-other-keys) + (use-modules (ice-9 regex)) + (let* ((pdmp-regex ".(emacs(-[[:xdigit:]]+)?.pdmp)-real") +(libexec (string-append (assoc-ref outputs "out") "/libexec")) -;; each of these find-files should return one file -(pdmp (find-files libexec "^emacs\\.pdmp$")) -(pdmp-real (find-files libexec - "^\\.emacs\\.pdmp-real$"))) - (for-each (lambda (wrapper real) - (delete-file wrapper) - (rename-file real wrapper)) - pdmp pdmp-real)) - #t)) +(pdmp (find-files libexec pdmp-regex))) + (map +(lambda (pdmp) + (rename-file + pdmp + (regexp-substitute #f (string-match pdmp-regex pdmp) 'pre 1))) +pdmp (add-after 'glib-or-gtk-wrap 'strip-double-wrap (lambda* (#:key outputs #:allow-other-keys) ;; Directly copy emacs-X.Y to emacs, so that it is not wrapped -- 2.33.1
bug#51348: Exception on `guix install nss-certs`
On Sat, Oct 23, 2021 at 10:57:20AM +, Raimundo Martins via Bug reports for
GNU Guix wrote:
> Hi! I'm having an exception when trying to install nss-certs. I have
> glibc-utf8-locales installed, and even tried installing glibc-locales even
> though my LANG=en_US.UTF-8.
> I'm running Guix the package manager on top of Void Linux.
Right, you can use glibc-utf8-locales (a random locale collection
intended for test purposes) to get en_US.UTF-8
> Throw to key `encoding-error' with args `("scm_to_stringn" "cannot convert
> wide string to output locale" 84 #f #f)'.
Did you set GUIX_LOCPATH, as suggested in the Application Setup section
of the manual?
https://guix.gnu.org/manual/en/html_node/Application-Setup.html
I'm not sure exactly which context this error occurs in, but I recommend
setting GUIX_LOCPATH in two places:
1) Your user's login environment. That is, ~/.bash_profile or equivalent
for your shell, like this:
export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale
Remember that you'll have to re-login to make it effective. This can be
done with `bash --login`.
2) The guix-daemon's environment. On Debian, that means adding a line
like this to the Service section of guix-daemon.service and reloading
and restarting the service:
Environment=GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale
Does Void Linux use runit instead of systemd? I'm sure there is a way to
export environment variables in service contexts with runit.
bug#51352: Matterbridge contained a lot of vendored code
On Sat, Oct 23, 2021 at 04:57:02PM +0200, Denis 'GNUtoo' Carikli wrote: > Given the huge amount of dependencies I was wondering what was the best > approach here: > - Would it makes sense to remove matterbridge from Guix, or should we > fix it instead? There's no need to remove it. Vendoring, or bundling, is not a matter of software freedom, but rather about maintainability or transparency. With a bundled dependency graph, the Guix tools for inspecting and manipulating the dependency graph do not work. But, we already bundle the dependencies of some other Go packages, and every Rust package does not work with the Guix dependency graph tooling.
bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others
On Fri, Oct 22, 2021 at 02:17:33PM -0700, Vagrant Cascadian wrote: > * Disable substitutes for relevent packages. Technically correct as > license incompatibility is only triggered on transmission of binary, > though maybe missing something about the spirit of the GPL. Maybe, but did anyone with standing ever take action regarding these licensing incompatibilities? Perhaps, looking at these issues too closely is also missing something about the spirit of the GPL.
bug#51352: Matterbridge contained a lot of vendored code
Hi, Am Samstag, den 23.10.2021, 16:57 +0200 schrieb Denis 'GNUtoo' Carikli: > Hi, > > When I sent the patch adding matterbridge to Guix, I only notified > that I didn't know if it contained vendored code or not at the last > moment (after the patch was sent, during the discussion about it, and > before it was merged). > > The issue is that I didn't know go at all and more specifically I > didn't know its the compilation system worked. So I managed to create > a package for matterbridge by looking at how it was done for other go > packages. > > After learning more about how go compilation worked, I found out that > matterbridge contained a lot of vendored code. Judging from the original issue, you did note that guideline and that you were unsure about the "under the hood" stuff, which imo should have prompted a closer look. CC'd Mathieu to check whether pushing it regardless was intentional. > And Guix explicitly wants to avoid bundles code. In the "16.6 > Submitting Patches" section of the manual[1], we have: > > 6. Make sure the package does not use bundled copies of software > > already available as separate packages. > And here while most dependencies are not already packaged, some are, > and I guess that I should read between the lines and conclude that > all the matterbridge dependencies should rather be packaged. > > So the question is what should we do about that. > > As I understand with the go build system, or you vendor all > dependencies, or you vendor none, and I've not yet managed to find a > way to workaround that yet in Guix (to do a progressive unvendoring). > > So instead I've started working on unvendoring matterbridge[2] > completely, but if we go this route, there are more than 500 > dependencies. > > To do that I first used the following command: > guix import go -r github.com/42wim/matterbridge > > I then started looking at each package definition that Guix didn't > manage to detect the license of, and I read the licenses to find if > they were free software. All the licenses I read were FSDG compliant. > Usually they had some extra text indicating the provenance of the > code or they would have multiple free software licenses. > > Then I started adding packages for the dependencies that guix import > go didn't manage to find. It's good that you've started. Perhaps you might want to illustrate the dependency "tree" (assuming it is one) or graph to roughly indicate how much needs to be done and at which points we could cut off portions of the DAG to process as batches. > Theses are repositories that are being forked from the official ones > for a reason or another. > > I've not finished that yet, but I still think it was a good idea to > open a bug report as I've now more understanding of the problem. > > Given the huge amount of dependencies I was wondering what was the > best approach here: > - Would it makes sense to remove matterbridge from Guix, or should we > fix it instead? I'll let Mathieu decide that one. > - If we fix it by packaging each dependencies, would it be ok if that > is done step by step, like if dependencies are packaged and patches > for them are sent, without necessarily a way to seriously test if > the packaged dependency work until they are used by other software > (like matterbridge)? Ideally, those packages would at least have a working test suite, but I understand that such concerns are not always valid in the industry :) As noted before, cutting off branches of the dependency DAG at reasonable points and committing them in batches sounds like a good idea to me. No one wants to review a 500 commit bomb. > Also when I'll manage to update matterbridge[3] how should we deal > with such amount of packages? Would I need to send one (generated) > patch for the upgrade of each package? One patch per package, plus one to fix the matterbridge package. > I also guess that sticking as much as possible to what Guix import go > generates would help in situations like that as it would make the > maintenance faster. The importers exist to make your life easier, but they're not omniscient. Please do exercise caution when dealing with them :) Cheers, Liliana
bug#51352: Matterbridge contained a lot of vendored code
Hi, When I sent the patch adding matterbridge to Guix, I only notified that I didn't know if it contained vendored code or not at the last moment (after the patch was sent, during the discussion about it, and before it was merged). The issue is that I didn't know go at all and more specifically I didn't know its the compilation system worked. So I managed to create a package for matterbridge by looking at how it was done for other go packages. After learning more about how go compilation worked, I found out that matterbridge contained a lot of vendored code. And Guix explicitly wants to avoid bundles code. In the "16.6 Submitting Patches" section of the manual[1], we have: > 6. Make sure the package does not use bundled copies of software > already available as separate packages. And here while most dependencies are not already packaged, some are, and I guess that I should read between the lines and conclude that all the matterbridge dependencies should rather be packaged. So the question is what should we do about that. As I understand with the go build system, or you vendor all dependencies, or you vendor none, and I've not yet managed to find a way to workaround that yet in Guix (to do a progressive unvendoring). So instead I've started working on unvendoring matterbridge[2] completely, but if we go this route, there are more than 500 dependencies. To do that I first used the following command: guix import go -r github.com/42wim/matterbridge I then started looking at each package definition that Guix didn't manage to detect the license of, and I read the licenses to find if they were free software. All the licenses I read were FSDG compliant. Usually they had some extra text indicating the provenance of the code or they would have multiple free software licenses. Then I started adding packages for the dependencies that guix import go didn't manage to find. Theses are repositories that are being forked from the official ones for a reason or another. I've not finished that yet, but I still think it was a good idea to open a bug report as I've now more understanding of the problem. Given the huge amount of dependencies I was wondering what was the best approach here: - Would it makes sense to remove matterbridge from Guix, or should we fix it instead? - If we fix it by packaging each dependencies, would it be ok if that is done step by step, like if dependencies are packaged and patches for them are sent, without necessarily a way to seriously test if the packaged dependency work until they are used by other software (like matterbridge)? Also when I'll manage to update matterbridge[3] how should we deal with such amount of packages? Would I need to send one (generated) patch for the upgrade of each package? I also guess that sticking as much as possible to what Guix import go generates would help in situations like that as it would make the maintenance faster. References: --- [1]https://guix.gnu.org/manual/en/guix.html#Submitting-Patches [2]https://git.replicant.us/contrib/GNUtoo/infrastructure/guix/log/?h=matterbridge-unvendor [3]Right now there is a compilation issue that I didn't manage to fix, even with help from #guix). Denis. pgpKwoSUj7Kgr.pgp Description: OpenPGP digital signature
bug#50592: Can't guix system init with grub-efi-bootloader from system that boots using grub-bootloader
The original wish to install to EFI NVRAM without EFI NVRAM is impossible; workarounds have been described. Closing. Regards, Florian
bug#51348: Exception on `guix install nss-certs`
Hi! I'm having an exception when trying to install nss-certs. I have
glibc-utf8-locales installed, and even tried installing glibc-locales even
though my LANG=en_US.UTF-8.
I'm running Guix the package manager on top of Void Linux.
I want to install nss-certs because curl, youtube-dl, and probably others all
complain about failure to verify certificates. I'm mentioning this because it
might be another bug altogether.
$ guix install nss-certs
The following package will be installed:
nss-certs 3.59
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
0.1 MB will be downloaded
nss-certs-3.59 130KiB 1.0MiB/s 00:00 [ ] 49.1%
Backtrace:
In guix/ui.scm:
2185:7 19 (run-guix . _)
2148:10 18 (run-guix-command _ . _)
In ice-9/boot-9.scm:
1752:10 17 (with-exception-handler _ _ #:unwind? _ # _)
1752:10 16 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/substitute.scm:
771:15 15 (_)
543:9 14 (process-substitution # _ "/gnu/store/?" ?)
In guix/serialization.scm:
424:4 13 (fold-archive _ _ _ _)
468:33 12 (read "/gnu/store/2f032p23rgga56kkn91q7hl0vzqyr7k5-nss?" ?)
468:33 11 (read "/gnu/store/2f032p23rgga56kkn91q7hl0vzqyr7k5-nss?" ?)
468:33 10 (read "/gnu/store/2f032p23rgga56kkn91q7hl0vzqyr7k5-nss?" ?)
468:33 9 (read "/gnu/store/2f032p23rgga56kkn91q7hl0vzqyr7k5-nss?" ?)
451:26 8 (read "/gnu/store/2f032p23rgga56kkn91q7hl0vzqyr7k5-nss?" ?)
520:21 7 (_ "/gnu/store/2f032p23rgga56kkn91q7hl0vzqyr7k5-nss-ce?" ?)
In ice-9/boot-9.scm:
1747:15 6 (with-exception-handler # ?)
In unknown file:
5 (symlink "NetLock_Arany_=Class_Gold=_F?tan?s?tv?ny:2.6?" ?)
In ice-9/boot-9.scm:
1685:16 4 (raise-exception _ #:continuable? _)
1685:16 3 (raise-exception _ #:continuable? _)
1780:13 2 (_ #< components: (#<> #)
1685:16 1 (raise-exception _ #:continuable? _)
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `encoding-error' with args `("scm_to_stringn" "cannot convert wide
string to output locale" 84 #f #f)'.
substitution of /gnu/store/2f032p23rgga56kkn91q7hl0vzqyr7k5-nss-certs-3.59
failed
guix install: error: some substitutes for the outputs of derivation
`/gnu/store/srh9xhqjd2r4giaq7x5gwbybqia6kc4r-nss-certs-3.59.drv' failed
(usually happens due to networking issues); try `--fallback' to build
derivation from source
PS: Great job on Guix!! With so many similar package managers out there, it was
about time someone actually invented something new!
bug#51341: gajim fails to start call
## Guix
guix 6cd33f8
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 6cd33f855c88e63849c96d5df7ca256dd0379f4a
## Versions
- OS: Linux
- GTK Version: 3.24.24
- PyGObject Version: 3.34.0
- GLib Version : 2.62.6
- python-nbxmpp Version: 2.0.2
- Gajim Version: 1.3.2
## Traceback
```
Traceback (most recent call last):
File
"/gnu/store/w4svc0x3azr64ik8jhbirapidncn3cbb-gajim-1.3.2/lib/python3.8/site-packages/gajim/chat_control.py",
line 719, in _on_call_with_mic
self._on_jingle_button_toggled(['audio'])
File
"/gnu/store/w4svc0x3azr64ik8jhbirapidncn3cbb-gajim-1.3.2/lib/python3.8/site-packages/gajim/chat_control.py",
line 954, in _on_jingle_button_toggled
sid = con.get_module('Jingle').start_audio(
File
"/gnu/store/w4svc0x3azr64ik8jhbirapidncn3cbb-gajim-1.3.2/lib/python3.8/site-packages/gajim/common/modules/jingle.py",
line 164, in start_audio
jingle.add_content('voice', JingleAudio(jingle))
File
"/gnu/store/w4svc0x3azr64ik8jhbirapidncn3cbb-gajim-1.3.2/lib/python3.8/site-packages/gajim/common/jingle_rtp.py",
line 359, in __init__
self.setup_stream()
File
"/gnu/store/w4svc0x3azr64ik8jhbirapidncn3cbb-gajim-1.3.2/lib/python3.8/site-packages/gajim/common/jingle_rtp.py",
line 374, in setup_stream
JingleRTPContent.setup_stream(self, self._on_src_pad_added)
File
"/gnu/store/w4svc0x3azr64ik8jhbirapidncn3cbb-gajim-1.3.2/lib/python3.8/site-packages/gajim/common/jingle_rtp.py",
line 116, in setup_stream
self.p2pstream.set_transmitter_ht('nice', params)
gi.repository.GLib.GError: fs-error: Could not create the nicesrc element (1)
```
## Steps to reproduce the problem
...
start a chat -> open options and click 'start Call...' -> click 'With
Microphone'
bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others
Vagrant Cascadian schreef op vr 22-10-2021 om 14:15 [-0700]: > [...] > Though, it is *possible* that various u-boot-BOARD in some cases > doesn't > include any openssl code at all in the resulting binaries, but builds > some tools used during the build process, that are then used to > produce > various cryptographic signatures in the build: > > https://lists.denx.de/pipermail/u-boot/2021-October/464533.html > > If that's true, it should be ok for various boards (though the > possibility of openssl code getting linked in would be hard to > catch). Add openssl to #:disallowed-references. Then the build will fail if the store item has a reference to openssl. This most likely won't catch uses of the _static_ OpenSSL libraries though, so the "openssl:static" input would need to be removed for this approach to work. Greetings, Maxime. -- not hacking on guix for a while, only occassionally looking at IRC logs and bug reports. E-mails are unsigned until backup is located.
bug#48462: Corrupt, un-repairable store after power cut during upgrade
Hi Guix, Am Sonntag, den 16.05.2021, 17:59 +0900 schrieb elaexuo...@wilsonb.com: > Hey Guix, > > Recently, during in the middle of a `guix package -m > .guix/manifest.scm`, my > machine had power failure. After rebotting, I simply reran the above > and it completed without error. > > However, it appears that some of files in the store items are > corrupt: > > [...] > As an extra bit of annoyance, the handy verify and repair tools fail > to see a problem: > > [...] > > Some questions: > > 1) Am I just missing something obvious? > 2) How could grafting end up producing empty files in the output? > 3) Is the store supposed to be robust against power failures? After dealing with some softer issues related to power outage during `guix package', I think I'm now able to say that Guix does not process grafts correctly during repair. What happened for me, was that certain store files were empty and when they were later grafted, those empty files were carried over. Guix, upon repairing the store, did then not regraft those, but rather kept them as-is. I have since fixed said issue by manually deleting the graft and rebuilding (this was possible, because nothing referred to it – I'm not sure why `guix gc' didn't pick it up as dead earlier, though). Stuff in my profiles seem to also have been rebuilt after roll-back+gc. So I think content repair needs to have at least two steps: 1. checking and repairing all "normal" derivations. 2. fixing grafts of packages that were repaired in step 1. WDYT?
bug#51141: guix home reconfigure does not apply changes to shepherd services
On 2021-10-22 02:32, Oleg Pykhalov wrote: > Andrew Tropin writes: > > […] > >> According to what I see in the shepherd tests: >> https://git.savannah.gnu.org/cgit/shepherd.git/tree/tests/replacement.sh?h=4c5176f5a7a5a1e7d7f258f585e8ed127a21b99a#n61 >> >> and how it's implemented in home-shepherd: >> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services/shepherd.scm?h=7c3f28fdc4edc00f66801cd51a5ba08eee44f77f#n59 >> >> It should work as you expect it. > > It doesn't. > >> Tried to do the following: I updated documentation field for a shepherd >> service, reconfigured and it got loaded after I restarted a service. >> >> ~ $ herd doc state >> Init, update and maybe destroy state. >> ~ $ herd restart state >> Service state has been stopped. >> Service state has been started. >> ~ $ herd doc state >> Really init, update and maybe destroy state. >> >> Didn't check if start action gexp is updated too, but I expect it was. > > The start action is the interest, or configuration record, or service > extension. From the experiment above it's clear that new configuration got loaded and service record get updated after restart (at least one field of it). > > (guix scripts system reconfigure) has a upgrade-shepherd-services > procedure, which was created in 240b57f0ca576708ebf6cfa0dfe2803fa9ff2323 > and discussed in https://issues.guix.gnu.org/22039 The difference with update-shepherd-services is the usage of Shepherd CLI in home service instead of Shepherd API in system service. So the problem can hide somewhere around this part. Automatic unloading in home-service doesn't happens and as I said it's by design to prevent cases of losing unsaved work. However, it can be implemented with an optional separate flag to shepherd configuration record and extension to run-on-change-service or as it done in system shepherd with the list of services, which doesn't have to be unloaded automatically. > > > [ The following text only describes how to reproduce the issue. ] > > > When I tried to write goimapnotify service no changes applied after > modifications in home-goimapnotify-shepherd-service [1] and [2], which > are typical service-type and record. I didn't have similar issues with > self-written system services. > > [1]: > https://gitlab.com/wigust/dotfiles/-/blob/ea2111906233099267f3b581b4aae39ad9645c2d/dotfiles/guixsd/modules/home/services/mail.scm#L28-45 > [2]: > https://gitlab.com/wigust/dotfiles/-/blob/ea2111906233099267f3b581b4aae39ad9645c2d/dotfiles/guixsd/home.scm#L40-65 > I'm out of office for next 1.5 week, will check it when I come back. > > Service extension also requires to unload service, e.g. mcron service > extension in [1] and [2]. > > [1]: > https://gitlab.com/wigust/dotfiles/-/blob/ea2111906233099267f3b581b4aae39ad9645c2d/dotfiles/guixsd/modules/home/services/package-management.scm#L16-50 > [2]: > https://gitlab.com/wigust/dotfiles/-/blob/ea2111906233099267f3b581b4aae39ad9645c2d/dotfiles/guixsd/home.scm#L154-161 > > If I remove the guix-delete-generations service from home configuration, > mcron job still exists according to 'herd schedule mcron'. > --8<---cut here---start->8--- > (home-environment > (services > (list (service guix-delete-generations-service-type ;; ... > > --8<---cut here---end--->8--- > > Oleg. BTW, please remove unreviewed changes to interpose function, they are incorrect. https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/configuration.scm?id=41492639e0223dc8fc1a357e1f9537577c055db7#n362 The explanation: https://issues.guix.gnu.org/50967#66 The correct version: https://git.sr.ht/~abcdw/rde/commit/4961f47c3f97c21799a39b3e906fa99b2625f331 -- Best regards, Andrew Tropin signature.asc Description: PGP signature
