bug#33844: Rename ghc-pandoc to pandoc
On Wed, Feb 26, 2020 at 12:23:14 +0200, Efraim Flashner wrote: > On Wed, Feb 26, 2020 at 11:06:30AM +0100, Pierre Neidhardt wrote: >> swedebu...@riseup.net writes: >> >> > Reason: it is used standalone to convert between formats. >> >> I agree. What do other people think? > > This is language specific, but like other language-specific packages > this is a package people would specifically search for as 'pandoc' and I > agree, it should be renamed. Ah, for the record, I had searched for pandoc using `guix package -s pandoc` in the past and didn't find what I was looking for, and so fell back to a Debian system. It turns out what I wanted was ghc-pandoc after all. But if I would have put a little bit more effort into looking, perhaps I would have figured that out; I was in a hurry. Thanks for making this change! -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 signature.asc Description: PGP signature
bug#36882: Qemu 4.2.0 build for x86_64-linux fails
Ludovic Courtès writes: > Incidentally, do we have problems building anything other than QEMU? The only other regression I've noticed with the C_INCLUDE_PATH change is that GHC 8.4 fails to build -- previously we at least got to GHC 8.6. The error message does not make much sense to me (something about libffi.so not found), but it must be related to the C_INCLUDE_PATH change since it built before. So I think we can work around these problems for now and try to fix it properly in the next core-updates cycle (rumor has it that it includes a switch to GCC 9 as well). signature.asc Description: PGP signature
bug#39727: statx error running 'guix gc' on CentOS 7
Hi Paul, Paul Garlick skribis: >> Great. Could you apply the following patch, run the daemon with: >> >> sudo -E ./pre-inst-env guix-daemon --build-users-group=… >> >> then run: >> >> guix gc -C42 > > Yes, all is good. > > I have re-built guix with your patch and started the daemon. Now 'guix > gc' runs as expected: Great, pushed as 513c0a0f4602018a49d8fd2dfa24670a3fa08ac9. Thanks, Ludo’.
bug#36882: Qemu 4.2.0 build for x86_64-linux fails
Hi,
Mathieu Othacehe skribis:
> About the environment issue, we have the same problem on master. You can
> run the following command:
>
> ./pre-inst-env guix environment -C -e '(@@ (gnu packages commencement)
> coreutils-final)' -- echo -e '#include \n int main() {return
> 0;}' > test.c && gcc -m16 -ffreestanding test.c
>
>
> and see that in takes stdint.h from the profile glibc header:
>
> In file included from
> /gnu/store/nl6zndkx4115laq50qmqcvnzinfz5rk0-profile/include/features.h:474:0,
> from
> /gnu/store/nl6zndkx4115laq50qmqcvnzinfz5rk0-profile/include/bits/libc-header-start.h:33,
> from
> /gnu/store/nl6zndkx4115laq50qmqcvnzinfz5rk0-profile/include/stdint.h:26,
> from test.c:1:
> /gnu/store/nl6zndkx4115laq50qmqcvnzinfz5rk0-profile/include/gnu/stubs.h:7:11:
> fatal error: gnu/stubs-32.h: No such file or directory
> # include
>^~~~
Indeed.
> So if it's ok for you, I'll try to implement a GCC hack so that we can
> keep using C_INCLUDE_PATH on core-updates and have QEMU building, as you
> proposed.
>
> About the environment use-case, it's getting really tricky, but as it is
> not a regression, we can maybe postpone the resolution.
Yes, both make sense to me.
>> Incidentally, do we have problems building anything other than QEMU?
>
> I don't know, but potentially any program building with -m
> and -ffreestanding fails on core-updates.
The evil idea I was getting at was that, if that’s just a couple of
packages, we can fix them locally. Evil plan in case the better hack
turns out to be tricky. :-)
Ludo’.
bug#39776: [PATCH] gnu: vim-full: Describe differences from vim
Jack Hill writes: > * gnu/packages/vim.scm (vim-full)[description]: New field. Explain what > vim-full provides over vim. Applied, thanks! signature.asc Description: PGP signature
bug#35589: Scribus and GIMP: Clipped, non-resizable windows and pixelated icons
Today I found out that the issue may be related to GNOME only, because the GIMP in sway works normally but the problem persists when in GNOME. GNOME version 3.32.2 $ gimp --version GNU Image Manipulation Program version 2.10.14 $ guix describe Generation 57 Feb 26 2020 12:28:15(current) guix b68f5a6 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: b68f5a68f895307ee184da725882d6f243ccded6
bug#39801: CUPS web admin page hangs
Hi,
The CUPS web interface in my Guix system hangs when loading the admin
page, making it cumbersome to manage CUPS printers and settings. The
cause appears to be that the web interface CGI scripts expect a config
file in the wrong location.
HOW TO REPRODUCE:
My system is running Guix commit 290b55c55a5 with the following CUPS
configuration:
(service cups-service-type
(cups-configuration
(web-interface? #t)
(log-level 'debug)
(extensions (list cups-filters
foomatic-filters
hplip-minimal
I load http://localhost:631/admin in a browser (Icecat). Expected
behavior is for the page to load immediately. Actual behavior is the
page hangs for a minute or two, displaying a blank screen. Eventually
the expected Administration page loads, but is missing some controls
and displays "Unable to open cupsd.conf file: Success."
DETAILS:
Excerpt from /var/log/cups/error_log is attached. Note especially
CUPS_SERVERROOT=/etc/cups.
Output of ‘ps -ef | grep cupsd’:
root 6374 1 0 00:29 ?00:00:01
/gnu/store/wxg6fa0d1hlna6gg2nrn51fkq68q7fy9-cups-2.3.1/sbin/cupsd -f
-c /gnu/store/6i13apvx94y7q61rh3hsj7fhjb6brgf4-cupsd.conf -s
/gnu/store/nxzmy9s6inia31wvhrcrzcf66rb4v4pp-cups-files.conf
Output of ‘sudo strace -p `pidof cupsd` -f -e file’ while refreshing
the Administration page contains a number of entries like this:
[pid 8423] access("/etc/cups/cupsd.conf", R_OK) = -1 ENOENT
(No such file or directory)
The directory /etc/cups exists but contains only ssl/ and ppd/
subdirectories, no cupsd.conf.
If I create a symlink /etc/cups/conf.d ->
/gnu/store/6i13...-cupsd.conf, the Administration page now loads
without any issue.
In addition, I noticed that (per Guix manual) the server-root field of
the CUPS service’s files-configuration section defaults to /etc/cups.
If I set that field to /gnu/store/wxg6...-cups-2.3.1/etc/cups (see the
cupsd command line above) then run ‘guix system reconfigure’ and
restart cupsd, the web interface again works as expected.
Finally, note that the ServerRoot field of
/gnu/store/nxzm...-cups-files.conf is set to
/gnu/store/wxg6...-2.3.1/etc/cups (again see cupsd command line
above).
COMMENTARY:
>From examining the CUPS sources, it appears the web admin interface
expects to find cupsd.conf in CUPS_SERVERROOT solely to make the "Edit
Configuration File" feature work. This feature doesn't seem very
useful on Guix since the config file lives in the (read-only) store.
However, the file still needs to be present in order to satisfy the
admin page CGI script and keep it from hanging.
Thus, perhaps the problem could be solved by having the service make a
symlink /etc/cups/cupsd.conf pointing at its generated cupsd.conf
file.
Thanks,
Jacob
log
Description: Binary data
bug#33844: Rename ghc-pandoc to pandoc
Pierre Neidhardt writes: > swedebu...@riseup.net writes: > >> Reason: it is used standalone to convert between formats. > > I agree. What do other people think? I agree. We should also rename all uses of ghc-pandoc in the same patch. -- Ricardo
bug#33844: Rename ghc-pandoc to pandoc
On Wed, Feb 26, 2020 at 11:06:30AM +0100, Pierre Neidhardt wrote: > swedebu...@riseup.net writes: > > > Reason: it is used standalone to convert between formats. > > I agree. What do other people think? This is language specific, but like other language-specific packages this is a package people would specifically search for as 'pandoc' and I agree, it should be renamed. -- 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
bug#33844: Rename ghc-pandoc to pandoc
Pierre Neidhardt 写道： Reason: it is used standalone to convert between formats. I agree. What do other people think? [Thumbs-up emoji] Kind regards, T G-R signature.asc Description: PGP signature
bug#33844: Rename ghc-pandoc to pandoc
swedebu...@riseup.net writes: > Reason: it is used standalone to convert between formats. I agree. What do other people think? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#39794: AVR-Toolchain-5 avr/io not found
Follow up of the problem:
Looks like what it's missing is `multilib`, avr-gcc-4.9 package description
clearly activates multilib and states that in a comment:
(define-public avr-gcc-4.9
(let ((xgcc (cross-gcc "avr" #:xgcc gcc-4.9 #:xbinutils avr-binutils)))
(package
(inherit xgcc)
(name "avr-gcc")
(arguments
(substitute-keyword-arguments (package-arguments xgcc)
((#:phases phases)
`(modify-phases ,phases
;; Without a working multilib build, the resulting GCC lacks
;; support for nearly every AVR chip.
(add-after 'unpack 'fix-genmultilib
(lambda _
;; patch-shebang doesn't work here because there are actually
;; several scripts inside this script, each with a #!/bin/sh
;; that needs patching.
(substitute* "gcc/genmultilib"
(("#!/bin/sh") (string-append "#!" (which "sh"
#t
((#:configure-flags flags)
`(delete "--disable-multilib" ,flags
...
But looks like the avr-gcc-5.5, which is just inheriting the same description,
is not able to create the multilib.
Any idea about why?
I think once we solve that we could have a reasonable avr-toolchain and also go
for newer versions.
Regards,
Ekaitz
ElenQ Technology
Ethical Innovation
