bug#49230: please update description for package nyacc
Matt Wette 写道： = 1.00 is a good breaking point. Thanks for doing this. -- Matt Done on master, closing. Kind regards, T G-R signature.asc Description: PGP signature
bug#49233: gmnisrv: missing mime.types
Hi, I am trying to use the gmnisrv service as described in the Guix manual, using the default configuration: (services (append (list (service gmnisrv-service-type) (service openssh-service-type) (service network-manager-service-type) (service wpa-supplicant-service-type)) %base-services)) However, gmnisrv keeps dying with this error: gmnisrv: src/mime.c:37: mime_init: Assertion `0' failed. Unable to open MIME database for reading: No such file or directory Is /etc/mime.types installed? Is the gmnisrv package or service missing a dependency that is supposed to provide the mime.types file, or am I supposed to copy one from somewhere? My system information: christopher@galadriel ~$ neofetch --stdout christopher@galadriel - OS: Guix System b36267b1d96ac344d2b42c9822ce04b4c3117f85 x86_64 Host: OptiPlex 7010 01 Kernel: 5.12.13-gnu Uptime: 24 mins Packages: 51 (guix-system), 35 (guix-user) Shell: bash 5.0.16 Terminal: /dev/pts/0 CPU: Intel i5-3570 (4) @ 3.800GHz GPU: Intel HD Graphics Memory: 93MiB / 15929MiB -- Christopher Howard blog: https://librehacker.com social: https://gnusocial.club/librehacker
bug#49230: please update description for package nyacc
On 6/26/21 6:13 AM, Tobias Geerinckx-Rice wrote: Matt Wette 写道： Could you please remove the "should be considered not stable" language from the description of the nyacc package? Thanks for reporting this, and thanks for nyacc! Guix ships four distinct versions of nyacc: nyacc 0.86 nyacc 0.99 nyacc 1.00.2, and nyacc 1.04.0 (the default). This still holds true on the current core-updates branch. I'd expect the warning to be accurate for the 0.x series, but maybe they turned out to be more stable than expected :-) Which version(s) of nyacc have ‘stable syntax and nomenclature’, and which (if any) did not? Kind regards, T G-R >= 1.00 is a good breaking point. Thanks for doing this. -- Matt
bug#49230: please update description for package nyacc
Matt Wette 写道： Could you please remove the "should be considered not stable" language from the description of the nyacc package? Thanks for reporting this, and thanks for nyacc! Guix ships four distinct versions of nyacc: nyacc 0.86 nyacc 0.99 nyacc 1.00.2, and nyacc 1.04.0 (the default). This still holds true on the current core-updates branch. I'd expect the warning to be accurate for the 0.x series, but maybe they turned out to be more stable than expected :-) Which version(s) of nyacc have ‘stable syntax and nomenclature’, and which (if any) did not? Kind regards, T G-R signature.asc Description: PGP signature
bug#49145: Cannot build Guix (Texinfo failure)
The process for translating the manual is as follows: we use po4a to replace English strings with the target language's strings. At this point, the translation contains English node names. Then, the Makefile is supposed to replace these with the actual translation of the node names (that way even untranslated strings refer to the correct nodes). However, it seems that in your case, that process did not go well. I'd rather try to fix the issue than avoid it, but you can always remove references to the translated manual from doc/local.mk. Can you try running the xref command from doc/local.mk manually, to see if it's doing anything wrong? Le 25 juin 2021 18:26:51 GMT-04:00, HiPhish a écrit : >I actually looked into the offending files and I found that they are >only half- >translated. Part of them is in German, but some parts are in English, >and the >English parts are referencing English node names, which obviously do >not exist >in the German manual. > >I do not need the German manual, is there a way to skip it? A quick >glance >shows the same problem in the Spanish manual as well, and other manuals >are >probably affected as well. I don't know why `make` only choked up on >the German >manual though. Maybe because that's the first one in alphabetical order >and >`make` did not bother trying the rest? Or could it be because my >machine is in >Germany? The output of the `locale` command is: > >$ locale >LANG=en_GB.UTF-8 >LC_CTYPE="en_GB.UTF-8" >LC_NUMERIC="en_GB.UTF-8" >LC_TIME="en_GB.UTF-8" >LC_COLLATE=C >LC_MONETARY="en_GB.UTF-8" >LC_MESSAGES="en_GB.UTF-8" >LC_PAPER="en_GB.UTF-8" >LC_NAME="en_GB.UTF-8" >LC_ADDRESS="en_GB.UTF-8" >LC_TELEPHONE="en_GB.UTF-8" >LC_MEASUREMENT="en_GB.UTF-8" >LC_IDENTIFICATION="en_GB.UTF-8" >LC_ALL= > >And when inside a pure Guix environment: > >$ locale >LANG= >LC_CTYPE="POSIX" >LC_NUMERIC="POSIX" >LC_TIME="POSIX" >LC_COLLATE="POSIX" >LC_MONETARY="POSIX" >LC_MESSAGES="POSIX" >LC_PAPER="POSIX" >LC_NAME="POSIX" >LC_ADDRESS="POSIX" >LC_TELEPHONE="POSIX" >LC_MEASUREMENT="POSIX" >LC_IDENTIFICATION="POSIX" >LC_ALL=
bug#48855: Segfault while attempting to use --with-git-url
Hello, Maxim Cournoyer skribis: > $ ./pre-inst-env guix build ppsspp \ > --with-git-url=ppsspp=https://github.com/hrydgard/ppsspp > > I get either > > updating submodule 'ext/SPIRV-Cross'... > indexing objects 91% > [## > ]Segmentation fault > > > or > > updating checkout of 'https://github.com/hrydgard/ppsspp'... > updating submodule 'dx9sdk'... > updating submodule 'ext/SPIRV-Cross'... > updating submodule 'ext/armips'... > receiving objects 73% > [ > ]Illegal instruction For the record, a possible workaround is: diff --git a/guix/git.scm b/guix/git.scm index 9c6f326c36..a180d12acc 100644 --- a/guix/git.scm +++ b/guix/git.scm @@ -291,7 +291,8 @@ dynamic extent of EXP." (format log-port (G_ "updating submodule '~a'...~%") name) (submodule-update submodule - #:fetch-options fetch-options) + #:fetch-options + (make-default-fetch-options)) ;; Recurse in SUBMODULE. (let ((directory (string-append This has to do with fetch options/progress callbacks being reclaimed too early. The backtrace upon segfault looks like this: --8<---cut here---start->8--- (gdb) bt #0 0x7f83dc798a3e in get_callee_vcode (thread=thread@entry=0x7f83dbe2fd80) at vm.c:1499 #1 0x7f83dc7a08a4 in scm_call_n ( proc=proc@entry=0xe0, argv=argv@entry=0x7ffe6426d200, nargs=2) at vm.c:1606 #2 0x7f83dc729fcc in invoke_closure (cif=0x7f83cbbfc580, ret=0x7ffe6426d420, args=0x7ffe6426d270, data=0xe0) at foreign.c:1100 #3 0x7f83dc463ed1 in ffi_closure_unix64_inner () from /gnu/store/bw15z9kh9c65ycc2vbhl2izwfwfva7p1-libffi-3.3/lib/libffi.so.7 #4 0x7f83dc464800 in ffi_closure_unix64 () from /gnu/store/bw15z9kh9c65ycc2vbhl2izwfwfva7p1-libffi-3.3/lib/libffi.so.7 #5 0x7f83c6e452a1 in do_progress_callback (stats=stats@entry=0xd843c0, idx=, idx=) at /tmp/guix-build-libgit2-1.1.0.drv-0/libgit2-1.1.0/src/indexer.c:562 #6 0x7f83c6e457cb in git_indexer_append (idx=0xdc3930, data=, size=, stats=0xd843c0) at /tmp/guix-build-libgit2-1.1.0.drv-0/libgit2-1.1.0/src/indexer.c:809 #7 0x7f83c6e9c6df in git_smart__download_pack (transport=0xda08a0, repo=, stats=0xd843c0, progress_cb=0x7f83d8da50b8, progress_payload=) at /tmp/guix-build-libgit2-1.1.0.drv-0/libgit2-1.1.0/src/transports/smart_protocol.c:582 #8 0x7f83c6e7a15b in git_remote_download (remote=remote@entry=0xd842f0, refspecs=refspecs@entry=0x0, opts=opts@entry=0x7ffe6426d808) at /tmp/guix-build-libgit2-1.1.0.drv-0/libgit2-1.1.0/src/remote.c:989 #9 0x7f83c6e7ae0e in git_remote_fetch (remote=0xd842f0, refspecs=refspecs@entry=0x0, opts=opts@entry=0x7ffe6426d808, reflog_message=reflog_message@entry=0x0) at /tmp/guix-build-libgit2-1.1.0.drv-0/libgit2-1.1.0/src/remote.c:1025 #10 0x7f83c6e909d9 in git_submodule_update (sm=0xd81360, init=1, _update_options=) at /tmp/guix-build-libgit2-1.1.0.drv-0/libgit2-1.1.0/src/submodule.c:1352 #11 0x7f83dc46466d in ffi_call_unix64 () from /gnu/store/bw15z9kh9c65ycc2vbhl2izwfwfva7p1-libffi-3.3/lib/libffi.so.7 #12 0x7f83dc462ac0 in ffi_call_int () from /gnu/store/bw15z9kh9c65ycc2vbhl2izwfwfva7p1-libffi-3.3/lib/libffi.so.7 #13 0x7f83dc72a33e in scm_i_foreign_call (cif_scm=, pointer_scm=, errno_ret=errno_ret@entry=0x7ffe6426dc9c, argv=0x7f83ce7d7880) at foreign.c:1073 --8<---cut here---end--->8--- To be continued… Ludo’.
bug#20255: 'search-paths' should respect both user and system profile.
Am Freitag, den 25.06.2021, 22:37 -0400 schrieb Maxim Cournoyer: > Hello, > > Alex Kost writes: > > > zimoun (2020-02-21 16:53 +0100) wrote: > > > > > Dear, > > > > > > What is the status of the bug#20255 [1]? > > > It is old; the last activity seems back on 2015, November. So let > > > resume. > > > > > > The issue is, e.g.: > > > - perl installed into the system profile > > > - perl-xml-parser installed into an user profile > > > Then "guix package --search-paths" does not set correctly > > > XML::Parser. > > > > > > > > > Fixes had been pushed: dedb17a and b2a7223 and cc3de1d. > > > > > > The final fix is still missing. Because it is a controversial > > > patch > > > [2] :-) i.e., running 'guix' in '/etc/profile'; see these lines > > > of the > > > patch: > > > > > > + eval `/run/current-system/profile/bin/guix package \\ > > > + -p /run/current-system/profile \\ > > > + -p \"$HOME/.guix-profile\" --search-paths` > > > > > > > > > The friendly "protest" [3] is about turning these lines optional > > > via > > > an environment variable. I am not sure to follow where the > > > discussion > > > had been going then. > > > > As for me, I am OK with any default setting as long as there is a > > way to > > change it. I recall Ludovic proposed a patch that allowed to > > customize > > "/etc/profile" and I was happy about it, but he changed his mind on > > that > > patch so it was never committed. > > Do you still have a vetted interest in the issue at hand? This is a > serious usability problem that's been in limbo for 6 years, > apparently > for reasons of purity (not wanting to run a command in /etc/profile). > While I share the sentiment that /etc/profile would better be 'inert' > or > static, it seems we haven't been able to come up with a better > solution > than calling 'guix package --search-paths'. Like Ludovic, I also > don't > find the idea of allowing users to override /etc/profile very > appealing; > even if undocumented, its mere presence in the operating-system field > would be an invitation for problems. An environment variable to > disable > such basic functionality also seems backward to me. > > I would personally be in favor of committing the fix as-is. If < 1 s > of > wasted time on boot is an issue, I suggest to look into GNU Shepherd > to > offset it; optimization opportunities should abound :-). I think there is a solution, that works not only for the case of disabling this unwanted feature, but also to add in support for multiple profiles, i.e. if the user has more than just their .guix- profile to load. If we made this feature opt-in in that a user would first have to write their profiles to $HOME/.config/guix/default-profiles or a similarly named file in $HOME/.config/guix, we could simply not run the command if the file doesn't exist, and if it exists run it using the profiles in there. Most users will likely have --8<---cut here---start->8--- /home/myself/.guix-profile /run/current-system/profile --8<---cut here---end--->8--- in it, but you could also have --8<---cut here---start->8--- /home/myself/.guix-extra-profiles/emacs /home/myself/.guix-extra-profiles/hundreds-of-npm-packages /home/myself/.guix-extra-profiles/rusty-rust /home/myself/.guix-profile /run/current-system/profile --8<---cut here---end--->8--- Of course, having to type out /home/myself is somewhat weird, and the last two lines are a bit of boilerplate, that one might want to avoid. We could alternatively make it so that an empty file means "use $HOME/.guix-profile and /run/current-system/profile", such that those are always sourced no matter what. WDYT? Regards, Leo
