bug#47115: Failure building grub-img.png when reconfiguring

On Sat, 13 Mar 2021, Mark H Weaver wrote: Thanks. Given this, and the lack of similar reports from others, my guess is that you hit a non-deterministic Guile bug, possibly the same one as (Non-deterministic failures while building Guix with Guile 3.0.5). If the pro

bug#47115: Failure building grub-img.png when reconfiguring

On Fri, 12 Mar 2021, Jack Hill wrote: On Fri, 12 Mar 2021, Mark H Weaver wrote: Jack: is the problem reproducible, or could it have been a sporadic failure? So far I've only reconfigured beyond the graft on the one VM, but with multiple commits. I'll try it on another host shortl

bug#47115: Failure building grub-img.png when reconfiguring

On Fri, 12 Mar 2021, Mark H Weaver wrote: Jack: is the problem reproducible, or could it have been a sporadic failure? So far I've only reconfigured beyond the graft on the one VM, but with multiple commits. I'll try it on another host shortly. Best, Jack

bug#47115: Failure building grub-img.png when reconfiguring

On Fri, 12 Mar 2021, Leo Famulari wrote: I wonder if it's related to the changes in the recent Cairo graft, from commit bc16eacc99e801ac30cbe2aa649a2be3ca5c102a? Yes, that seems to be it. The previous commit sudo -E guix time-machine --commit=453e101fc3f7dac9aabcd6122cf05fb7925103c7 -- syste

bug#47115: Failure building grub-img.png when reconfiguring

tloader (bootloader-configuration (bootloader grub-bootloader) (target "/dev/vda") (terminal-outputs '(console (file-systems (cons (file-system (mount-point "/") (

bug#44117: Racket no longer fails to build

I believe this is a an old build failure report that has been fixed in subsequent changes to the racket package. Therefore, I'm closing this bug. Feel free to reopen if I am mistaken and it is still relevant. Best, Jack

bug#47064: DrRacket internal error uncompressing

Hi Guix, Using guix 80739ea480a7db667b83b45e3a08be740449f689 on x86_64, running: `guix environment --ad-hoc racket -- drracket` produces: ``` $bytevector-uncompress: internal error uncompressing #"\0\0\0\0chez\310\224\206:\r()#\201\256R-d\205\233\24\363\5\20\201P\6A\v\300\0\16\f\6\31\2\f\6\f&H

bug#46333: sbcl-common-lisp-jupyter does not install kernel.json

Hi Guix, The sbcl-common-lisp-jupyter package does not install a kernel.json file. That's the file that tells Jupyter about the kernel and how to run it, and should be installed in /share/jupyter/kernels//kernel.json. sbcl-common-lisp-jupyter doesn't come with a kernel.json file to install,

bug#45974: guix system vm-image ignores filesystem type

Hi Guix, I believe that this is a feature request. I would like to create a Guix qcow2 image to run as a VM. Additionally, I would like the root file system to be btrfs. Therefore, I created an operating system definition with the following file-systems: ``` (file-systems (cons (file-system

bug#45172: fiano-fmap test failure

Hi Guix, fiano-fmap fails to build with a test failure. I'm using guix 937bc5841429f40a64e6b25d5d4c2fe3276789f1. The log from the check phase is: """ starting phase `check' # github.com/linuxboot/fiano/cmds/fmap package github.com/linuxboot/fiano/cmds/fmap (test) imports github.com/u-r

bug#36620: alpine crashes while sending mail

I'm no longer seeing this problem with the latest alpine, 2.24 from guix 0e25fe420e710cbea84b7410964481468d14150f, so this issues can be closed. Best, Jack

bug#43963: webssh missing source files

Hi Guix, Using guix fb0037af8cecc0ebaa330392b0c54a35b7b8a424, webssh source contains obfuscated javacript in webssh/static/js, without corresponding source files. I would like for these to generated from source javascript as part of the build process. As a bonus they should probably be de-bu

bug#42543: lint failure for packages on load path specified with -L

On Sun, 23 Aug 2020, Ludovic Courtès wrote: I’ve fixed the root issue with d10474c38d58bdc676e64336769dc2e00cdfa8ed (avoiding ‘canonicalize-path’). Awesome, thank you!

bug#42773: sbcl-hu.dwim.common is missing a description

The description for sbcl-hu.dwim.common is empty. This is with Guix 8e6344a5fb22e2614dcb0db8e24658e63c6121c7. Best, Jack

bug#42543: lint failure for packages on load path specified with -L

Hi Ludo’! Hope you've enjoyed your (short) time away from the keyboard :) On Wed, 5 Aug 2020, Ludovic Courtès wrote: Hi, Jack Hill skribis: jackhill@alperton ~$ guix lint -L lint-test my-hello Backtrace:y-hello@2.10 [formatting]... 8 (primitive-load "/home/jackhill/.c

bug#42543: lint failure for packages on load path specified with -L

On Mon, 27 Jul 2020, zimoun wrote: Dear, The issue was in the “formatting” and “source” checkers, something inconsistent with other parts (see “search-path %load-path”). Therefore, “--load-path=path/to/modules” is now ’canonicalize-path’, directly in “(guix scripts build)%standard-build-option

bug#42543: lint failure for packages on load path specified with -L

I believe that this problem is in the formatting checker. As I understand it, that checker reads the actual sorece file. With that information, I tried re-running link the the full path passed to -L, and it works as expected: guix lint -L /home/jackhill/lint-test my-hello passing just the rel

bug#42543: lint failure for packages on load path specified with -L

Hi Guix, I'm running guix from commit 30aa5dd7e7180d163d409b080bf89e8a15a5ba4d. I've created a package in local directory lint-test. `guix lint` errors when processing this package, but other guix commands like build and show work as expected. A session with these commands: ``` jackhill@alpe

bug#42315: `guix system vm-image` does not produce image with btrfs

systems (cons (file-system (mount-point "/") (device "/dev/vda1") (type "btrfs") (flags '(no-atime)) (options "compress=zstd"))

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

On Tue, 9 Jun 2020, Chris Marusich wrote: - Try building with different kernel versions on the same machine, to see if they differ. I've done the rebuild after updated from Linux 5.4.41 to 5.4.45, and go identical results to my previous build. I am using a different kernel configuration tha

bug#41174: [PATCH] gnu: webkitgtk: Add patch to share all fonts.

On Tue, 26 May 2020, Leo Prikler wrote: Hi, I don't see anything in the patch itself, that is specific to Guix, so it should probably work upstream as well. This issue is likely going to affect other functional package managers like Nix too, so it would be nice, if we can get the patch to be a

bug#41174: [PATCH] gnu: webkitgtk: Add patch to share all fonts.

On Tue, 26 May 2020, Leo Prikler wrote: * gnu/packages/patches/webkitgtk-bind-all-fonts.patch: New file. * gnu/packages/webkit.scm (webkitgtk)[source]: Use it here. * gnu/local.mk: Add it here. --- gnu/local.mk | 1 + .../patches/webkitgtk-bind-all-fonts.patch

bug#41058: GNOME Maps fails to start in GNOME

On Sun, 10 May 2020, Marius Bakke wrote: sirgazil via Bug reports for GNU Guix writes: I still can reproduce the problem though, in both real and virtual machines. Oh, I had missed that you mentioned it worked from a terminal (it did not for me on i3). I hope one of the GNOME users around

bug#40837: core-updates: webkitgtk web process sandbox incomplete

On Wed, 6 May 2020, Marius Bakke wrote: Hello Jack, Thanks a lot for this work. You're welcome. I'm happy that we seem to be making good progress. Jack Hill writes: Some additional observations: With my patched webkitgtk, if I set: PULSE_CLIENTCONFIG=

bug#35085: emacs reproducability problem also affects emacs-next 27.0.91

Hi, I filed a duplicate bug earlier today while working on emacs-next. The problem now also seems to include the new .pdmp files. Best, Jack

bug#41012: emacs-next does not build deterministically

On Fri, 1 May 2020, Jack Hill wrote: For me, emacs-next does not build deterministically. I should add, this is master at commit 26e11cffb983604c813064343e41708b99072e4f I also just tested emacs 26.3, and that also build non-deterministically. If this is a known problem, I apologize, but

bug#40837: core-updates: webkitgtk web process sandbox incomplete

After further discussion on the Bubblewrap issue [0], it was determined that the problem should be fixed by having WebKitGTK canonicalize paths before passing them to bwrap. There is now a WebKit issue for that fix [1]. [0] https://github.com/containers/bubblewrap/issues/195 [1] https://bugs.we

bug#40837: core-updates: webkitgtk web process sandbox incomplete

I'm a little bit unstuck now. I found a bubblwrap issue [0], which I believe is the one that we're running into. [0] https://github.com/containers/bubblewrap/issues/195 "Errors when --bind used with a symlinked path" With insight gained there, I've determined that the following simplified bw

bug#40837: core-updates: webkitgtk web process sandbox incomplete

I didn't have any better luck with the Nix patch. I was also unable to any problems with /etc/pulse/client.conf when calling bwrap manually on the command line. I'm afraid that I'm stuck for now. I have asked the WebKit developers for help: https://lists.webkit.org/pipermail/webkit-dev/2020-Ap

bug#40837: core-updates: webkitgtk web process sandbox incomplete

Some additional observations: With my patched webkitgtk, if I set: PULSE_CLIENTCONFIG=/gnu/store/zc4dsmvdabi00nvisrjhi9w00ff4igs7-client.conf it does work, which is an improvement compared to without the patch. I notice that Nix [0] has a similar patch: """ diff -ru old/webkitgtk-2.26.0/Sour

bug#40837: core-updates: epiphany web process crashes

On Sat, 25 Apr 2020, Jack Hill wrote: in Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp of WebKitGTK, I set the PULSE_CLIENTCONFIG environemnt variable to the store path rather than /etc/pulse/client.conf, which is what it was set to before. That allowed epiphany to get past

bug#40837: core-updates: epiphany web process crashes

I now think what is being shared with bubblewrap is on the write track. After seeing """ const char* pulseConfig = g_getenv("PULSE_CLIENTCONFIG"); if (pulseConfig) bindIfExists(args, pulseConfig); """ in Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp of WebKitGTK, I set the P

bug#40837: core-updates: epiphany web process crashes

On Sat, 25 Apr 2020, sirgazil via Bug reports for GNU Guix wrote: I can reproduce this bug. I can't load any page and see the same messages in the terminal. Thanks, as a fist step it is helpful to know that the problem can be reproduced. The second step is to figure out why this is happeni

bug#40837: core-updates: epiphany web process crashes

I expericne the problem with epiphany installed both in the system profile and in an ad-hoc environment. Best, Jack

bug#40837: core-updates: epiphany web process crashes

Hi Guix, On Guix System with the current core-updates branch, epiphany/GNOME-Web starts, but doesn't work because the web process crash in a loop. When I run epiphany from the terminal I see """ $ epiphany ** (epiphany:29457): CRITICAL **: 22:37:21.415: void webkit_web_context_register_uri_

bug#40829: [PATCH core-updates] gnu: pdfpc: Upgrade to 4.4.0

* gnu/packages/pdf.scm (pdfpc): Upgrade to 4.4.0. --- gnu/packages/pdf.scm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gnu/packages/pdf.scm b/gnu/packages/pdf.scm index 8ccb133e1f..f4ffda7462 100644 --- a/gnu/packages/pdf.scm +++ b/gnu/packages/pdf.scm @@ -1232,7 +1232,

bug#40829: [core-updates] pdfpc-4.3.4 fails to build

Hi Guix, Currently, pdfpc on core-updates fails to build with: /tmp/guix-build-pdfpc-4.3.4.drv-0/source/src/classes/action/action_mapping.vala:51.9-51.28: error: Creation method of abstract class cannot be public. public ActionMapping() { /tmp/guix-build-pdf

bug#40819: [core-updates] font-gnu-freefont fails to build

Hi Guix, On the current core-updates branch, font-gnu-freefont fails to build with the attatched build log. Based on the messages about syntax errors, it looks like gnu-freefont is not compatible with python3, and instead needs python2. However, we already try to do this in the package defi

bug#40478: feature request/idea: guix pull --news should show information about new package replacements

Hi Guix, I'm an avid reader of `guix pull --news`. I like learning about new and updated software. However, I noticed that when a package gains a new replacement (e.g. for a security fix via grafting), it is not mentioned. We do not show all changes to package definitions in the new, but since

bug#25201: [PATCH] gnu: Patch mumble to disable statistic gathering by default.

On Tue, 10 Mar 2020, m...@rohleder.de wrote: Hi Jack, Jack Hill writes: I'm trying to follow along, and learn some things about making Guix packages. One question I have after seeing this change is how did you decide whether to make this change in the source definition (with a patch

bug#25201: Re bug#25201: [PATCH] gnu: Patch mumble to disable statistic gathering by default.

Hi, Thanks for improving Guix! Having an old bug closed is great. I'm trying to follow along, and learn some things about making Guix packages. One question I have after seeing this change is how did you decide whether to make this change in the source definition (with a patch or a snippet) o

bug#39776: [PATCH] gnu: vim-full: Describe differences from vim

--- a/gnu/packages/vim.scm +++ b/gnu/packages/vim.scm @@ -8,6 +8,7 @@ ;;; Copyright © 2019 HiPhish ;;; Copyright © 2019 Julien Lepiller ;;; Copyright © 2019, 2020 Jakub Kądziołka +;;; Copyright © 2020 Jack Hill ;;; ;;; This file is part of GNU Guix. ;;; @@ -131,6 +132,8 @@ ("t

bug#39776: Explain difference between vim and vim-full (feature request)

On Tue, 25 Feb 2020, Leo Famulari wrote: On Tue, Feb 25, 2020 at 12:44:30AM -0500, Jack Hill wrote: Hi Guix, This is an enhancement request: I think we should explain what vim-full provides over vim in the package description. What do you think? Absolutely! Who will write the patch

bug#39776: Explain difference between vim and vim-full (feature request)

Hi Guix, This is an enhancement request: I think we should explain what vim-full provides over vim in the package description. What do you think? All the best, Jack

bug#39696: linux-libre >= 5.4.20 network interfaces, gdm or Xorg and lvm stopped working

On Thu, 20 Feb 2020, Sam P wrote: 1. No ethernet interface is shown only lo: is shown 2. gdm, Xorg totally stopped working 3. lvm command vgchange -ay taken forever and not able to create device node in /dev/mapper Sam, Sorry to hear that you're experiencing this problem. This sounds to me

bug#39671: Something appears to disable linux kernel modules from loading.

On Wed, 19 Feb 2020, Ludovic Courtès wrote: The kernel’s lazy module loading mechanism invokes this program, which should just work. Does /run/current-system/profile/bin/modprobe exist? Yes, it is a symlink to /gnu/store/d064bv2b1hrb07j2zj78i608db7qldx9-kmod-26/bin/modprobe Any hints in “

bug#39681: Manual typo in section "Invoking ‘guix time-machine’"

Tags: easy Hello Guix, In the manual section 4.8, "Invoking ‘guix time-machine’", I believe that "are passed unmodified to the ‘guix’ command if the specified revision," would read better if it said, "to the ‘guix’ command of the specified revision." I've filed this as a bug like #39417 as

bug#39671: Something appears to disable linux kernel modules from loading.

On Wed, 19 Feb 2020, Ludovic Courtès wrote: What does “cat /proc/sys/kernel/modprobe” return on the broken system? /gnu/store/daq5zs7ni529zh3xxgyhidna52wa17js-modprobe The contents of that file are: """ #!/gnu/store/1mkkv2caiqbdbbd256c4dirfi4kwsacv-guile-2.2.6/bin/guile --no-auto-compile !#

bug#39637: mongo-tools test fail with Go 1.13

On Sun, 16 Feb 2020, Jack Hill wrote: I have opened a bug report upstream: https://jira.mongodb.org/browse/TOOLS-2482 Upstream reports, "MongoDB 3.4 is now EOL so it is no longer supported. For MongoDB Tools specifically, we're only making critical fixes to versions <4.2.&q

bug#39637: mongo-tools test fail with Go 1.13

Hi Guix, After the recent Go 1.13 update, the test for mongo-tools package (currently at vervsion 3.4.0) fails with: ``` flag provided but not defined: -test.testlogfile Usage of /tmp/guix-build-mongo-tools-3.4.24.drv-0/go-build972699285/b001/mongofiles.test: -convey-json When true,

bug#39603: go-ipfs 0.4.22 fails to build

Hi, It appears that go-ipfs 0.4.22 is not compatible with the recent upgrade to go 1.13. Fortunately, upstream has made a maintainance release that includes the support for go 1.13: https://github.com/ipfs/go-ipfs/releases/tag/v0.4.23 I've submitted a patch to update go-ipfs in https://issu

bug#39281: gdm doesn't start

On Tue, 28 Jan 2020, sirgazil wrote: The initial setup window did not appear in my case, but I assume it is because somewhere in my system something says I already went through the setup (I did see the window in a previous boot). I beilieve this it tell if it has already run by looking for by

bug#39281: gdm doesn't start

On Tue, 28 Jan 2020, Leo Prikler wrote: I've attached a patch, that should take care of this bug. So far, I've only tested it in a VM (with the package added back into gnome), so it would be nice if one of you could test this with a real reboot before commiting. I'm happy to report that after

bug#39281: gdm doesn't start

On Mon, 27 Jan 2020, Danny Milosavljevic wrote: Hi, hmm, if you want to find out whether we could fix it, could you invoke: useradd gnome-initial-setup I added gnome-initial-setup to my operating system config and reconfigured with 94600c3960d7e2f12a3a9b6d2ed0d98ddacdd055 (the commit before

bug#39281: gdm doesn't start

On Mon, 27 Jan 2020, sirgazil wrote: Was the patch already applied? Because I just pulled, reconfigured and I have the same problem: After a message like this No, the patch wasn't applied, as we're still not sure if there is a better fix. I applied it to my local copy of guix [0] to test. If

bug#39281: gdm doesn't start

On Mon, 27 Jan 2020, Raghav Gururajan wrote: so I removed gnome-initial-setup from the propagated-inputs with the following patch, and, indeed, that resolved the problem with gdm on my system. That's strange. Both our system share similar configuration. But for me gdm works fine with gnome-i

bug#39281: [PATCH] gnu: gnome: don't propagate gnome-initial-setup

Fixes bug#39281 * gnu/packages/gnome.scm (gnome)[propagated-inputs]: remove gnome-initial-setup --- gnu/packages/gnome.scm | 1 - 1 file changed, 1 deletion(-) diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm index e843bdfe08..9db379744a 100644 --- a/gnu/packages/gnome.scm +++ b/gn

bug#39281: gdm doesn't start

According to my git bisect, d36fa50fbf8169018193774782fd21f1b13b9c0e [0] is the culprit. It makes some sense that the commit is gnome-related, but I have no idea why adding more packages to the environment should cause gdm to fail to run properly. Therefore, I am inclined to believe that it is

bug#39281: gdm doesn't start

I've started bisecting between my known bad and good commits. Unfortunately, this will be a slow process both because my computer is only so fast, and because rebooting to check a commit disrupts other work. That said, why checking one of the bad commits, I noticed that the gdm process was ind

bug#39281: gdm doesn't start

nt-point "/") (type "ext4") (dependencies mapped-devices)) %base-file-systems)) (swap-devices (list "/root/swap")) (users (cons (user-account (name "jackhill") (comment "Jack Hill"

bug#38940: \x1b]8; ; OSC character displayed on hyperlinks shown after calls to `guix describe` or `guix show` on mate-terminal 1.12.1 (Trisquel 8)

Hi Ludo' On Thu, 9 Jan 2020, Ludovic Courtès wrote: 1. Instead of INSIDE_EMACS, the variable name NO_SUPPORT_HYPERLINK or other seems more meaningful. Maybe? Actually the goal was to remove ‘INSIDE_EMACS’ from there once a widespread-enough Emacs version supports it, which could be within a y

bug#38359: Mistaken merge

Oops, I didn't mean to merge this bug with the other ones. I'll look up how to unmerge shortly. Apologies, Jack

bug#38186: dd doesn't copy whole file when specifying units with bs

On Tue, 12 Nov 2019, Clément Lassieur wrote: Does this[1] help? [1]: https://superuser.com/questions/730801/dd-immidiately-completes-but-actually-needs-sync Indeed it does. I guess I just got lucky with the second invocation that data got written out. Thanks very much for the pointer, and s

bug#38186: dd doesn't copy whole file when specifying units with bs

Hi Guix, It seems that my version of dd from coreutils-8.31 does not seem to work correctly when using units with the bs option (e.g. bs=1M). In the terminal session below, I first use bs=1M. The output looks okay: dd appears to have copied the whole 2.3GiB file, but it has done so impossibly

bug#36519: System frequently suspending after logout

rg/archive/html/help-guix/2019-10/msg00213.html In the second email, Jack Hill describes a potential work-around. I wonder if it might also work for the issue described in this bug report? It seems like a slightly different issue. At least, I don't remember running into this. However, it se

bug#38064: Simple Scan: Scanner is not detected

On Mon, 4 Nov 2019, sirgazil via Bug reports for GNU Guix wrote: I can't use the scanner because Simple Scan (a.k.a. Document Scanner) does not detect it. That's unfortunate. I think the follow information might help in troubleshooting: What scanner is it, and how is it connected (e.g. USB

bug#37911: Cannot build a system with colord-service.

On Sat, 2 Nov 2019, Ludovic Courtès wrote: Commit 33f9778bc83086837b99e5c5e99cd514cb0d154e fixes this and colord now starts correctly again. I believe that should also fix the “night light” feature in GNOME. I tested it in a VM but it was hard to tell if it was working. Could you confirm, Jac

bug#37911: Cannot build a system with colord-service.

On Thu, 24 Oct 2019, Pierre Langlois wrote: In gnome's settings it tells me that there are no devices that can be colour managed, I had assumed that was because colord was missing from the config but that's probably not it. Is it working for other people? If so it's probably just my hardware (Th

bug#37843: GNOME night light doesn't change colors with GNOME 3.30

%base-file-systems)) (swap-devices (list "/root/swap")) (users (cons (user-account (name "jackhill") (comment "Jack Hill") (group "users") (supplementary-groups '("wheel" "netdev"

bug#35853: gnome-tweaks can now manage gnome-extentions

Hi Guix, After the recent core-updates merge and update to gnome 3.30, the gnome-tweaks extension management is working again. Closing issue. Best, Jack

bug#37680: [PATCH] gnu: simple-scan: Update to 3.34.1

* gnu/package/gnome.scm (simple-scan): Update to 3.34.1 [build-system]: Switch to meson-build-system. [source]: Fetch from GNOME mirrors. [inputs]: Add libwebp. [native-inputs]: Remove colord. [arguments]: Remove #:configure-flags. Remove 'clean phase. [home-page]: Update to current home-page. ---

bug#37503: dconf-editor build fails on core-updates

Hi Guix, While trying out core-updates with the following guix $ guix describe Generation 15 Sep 24 2019 10:40:50(current) guix 2cf9798 repository URL: https://git.savannah.gnu.org/git/guix.git branch: core-updates commit: 2cf9798e1688c28d33d12d360e7869207eca18d7 dconf-edito

bug#36419: webkitgtk fixed in later release?

Today I was able to build webkitgkt 2.24.4 with Guix commit 4343eebfc9f7d44ec9a665f3374d1397301b542e. It looks like it is also available on ci.guix.gnu.org: https://ci.guix.gnu.org/25hz999kgcjh4alm6liwm12jm3blf5zz.narinfo This is a newer release of webkitgtk than the one that failed (2.24.2).

bug#37421: Apply nodejs test workaround?

Hi Guix, I wanted to ping this issue. From the discussion in #37421, it seems like we are OK with disabling the problematic tests as a work-around for now. Should we go ahead and apply the patch? Best, Jack

bug#37248: GNOME and Icecat problems

On Mon, 2 Sep 2019, Jonathan Lane wrote: I got a very similar error message on the gnome-tweaks part of my bug report, and it can be considered a duplicate of that issue. $ gnome-tweaks ** (..gnome-tweaks-real-real:2189): WARNING **: 11:47:39.372: Failed to load shared library 'libsoup-2.4.so

bug#37248: GNOME and Icecat problems

On Sat, 31 Aug 2019, j...@dorsal.tk wrote: There are several problems with using GNOME 3.28 and Icecat 60 on Guix, many of which impact each other. 1. The gnome-tweaks package can't find gnome-shell extensions from the gnome-shell-extensions package, and so claims none are installed. This is

bug#36961: Can't use microphone in ungoogled-chromium

I think that this is related to the same thing that is being discussed in upstream issue 785 . In particular, it looks like Guix is disabling audio capture ins master-preferences.json

bug#36710: emacs-org build failure

Hi Guix, On my local system emacs-org fails to build with the following output using $ guix describe Generation 6Jul 17 2019 15:11:42(current) guix 82ccfb1 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 82ccfb1d9464c8487bbb2eb4f5871b8fdb5

bug#36620: alpine crashes while sending mail

s : 119.7 last-version-used : 6.21. user-input-timeout : 0 encryption-protocol- : no_min,no_max remote-abook-history : 3 remote-abook-validit : 5 printer : attached-to-ansi patterns-roles : LIT:pattern="/NICK=Duke/FROM=jackh...@duke.edu/FLDTYPE=EMAIL&qu

bug#36419: (no subject)

The previously attatched log was generated with -c 12. I am currently running a build with -c 1 to verify that the problem occurs there as well. (I remember it happening with -c 1 in the past, but my memory could be faulty).

bug#36207: Circular dependency in gnu/services: mcron -> base -> admin -> mcron

On Sat, 15 Jun 2019, Ludovic Courtès wrote: This is fixed (surprisingly easily!) by commit f3d797005374e5333c7596fe86b4a524ab1b9b11. Neat! Let me know if you notice anything wrong! Everything looks good and works well for me. Thanks for the bug report, Thanks for the quick fix. Best,

bug#36207: Circular dependency in gnu/services: mcron -> base -> admin -> mcron

Hi Guix, As discussed on IRC with Ludo’ and Ricardo, 4252dace19945f56192477e8cb07973c20a526ba introduced a circular dependency among gnu/services modules, by adding a dependency between from base -> admin, resulting in the full dependency chain: mcron -> base -> admin -> mcron I ran into t

bug#35919: recutils package does not install emacs rec-mode

On Mon, 10 Jun 2019, Oleg Pykhalov wrote: I have prepared the following patch implementing this suggestion (thanks again, I'm much happier with this). I ended up putting it in databases.scm rather than emacs-xyz.scm so that it can live with the recutls definition, and not run afoul of the advice

bug#35919: [PATCH] gnu: recutils: remove emacs-minimal native input

From 6cb65ab8ae2a0cb239cc476a6859ab407cec30e2 Mon Sep 17 00:00:00 2001 * gnu/packages/databases.scm (recutils) [native-inputs]: Remove emacs-minimal --- gnu/packages/databases.scm | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/gnu/packages/databases.scm b/gnu/packages/dat

bug#35919: recutils package does not install emacs rec-mode

I realized that emacs-minimal should also be removed from the native-inputs of recutils since it is not being using during the build.

bug#35919: [PATCH] gnu: Add emacs-recutils

index ad4698f24c..30821e330b 100644 --- a/gnu/packages/databases.scm +++ b/gnu/packages/databases.scm @@ -33,6 +33,7 @@ ;;; Copyright © 2018 Amirouche Boubekki ;;; Copyright © 2018 Joshua Sierles, Nextjournal ;;; Copyright © 2018 Maxim Cournoyer +;;; Copyright © 2019 Jack Hill ;;; ;;; This

bug#35919: recutils package does not install emacs rec-mode

On Sun, 9 Jun 2019, Oleg Pykhalov wrote: WDYT about creating a new package recipe in ‘gnu/packages/emacs-xyz.scm’, which inherits ‘recutils’ and sets build system to ‘emacs-build-system’? We will probably need to change directory after unpack phase in this case, but we will not need to maintain

bug#35919: recutils package does not install emacs rec-mode

On Sun, 9 Jun 2019, Oleg Pykhalov wrote: WDYT about creating a new package recipe in ‘gnu/packages/emacs-xyz.scm’, which inherits ‘recutils’ and sets build system to ‘emacs-build-system’? We will probably need to change directory after unpack phase in this case, but we will not need to maintain

bug#35919: recutils package does not install emacs rec-mode

On Sat, 8 Jun 2019, Jack Hill wrote: I'll ask the recutils upstream if this was intentional. I have done so at: <https://lists.gnu.org/archive/html/help-recutils/2019-06/msg0.html> In the meantime, what do we want to do in Guix? I see two options: one is patching the build

bug#35919: recutils package does not install emacs rec-mode

I've looked at this some, and it looks to me like it is a change in the upstream build system. I can confirm that the problem arrived in Guix when the package version was updated from 1.7 to 1.8. In particular, it looks like lispdir is no longer being set by configure. The configure from 1.7 ha

bug#36076: Manual should clarify that glibc-utf8-locales is needed by default on foreign distros

On Fri, 7 Jun 2019, Ludovic Courtès wrote: Fixed in 0e6cee21a48294b81a5e57e00602728fe7f7075f, thanks! Awesome, thanks for the developing the fix! Jack

bug#36076: Manual should clarify that glibc-utf8-locales is needed by default on foreign distros

On Thu, 6 Jun 2019, Ludovic Courtès wrote: Let me know what you think. I follow all of the explanation, so it makes sense to me. Previously, I didn't know about normalized names, but now I do, so thanks! Once normalized locales are present in glibc-locales, I don't think any change will be

bug#36076: Manual should clarify that glibc-utf8-locales is needed by default on foreign distros

Hi Ludo’ On Wed, 5 Jun 2019, Ludovic Courtès wrote: I honestly don’t see how it could be clearer: https://www.gnu.org/software/guix/manual/en/html_node/Application-Setup.html#Locales Could you propose a patch to this section? I think what is missing is a statement that the systemd unit fo

bug#36076: Manual should clarify that glibc-utf8-locales is needed by default on foreign distros

tarball? [1] https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh I used the shell install script. Jack Hill writes: [...] application setup. I installed the glibc-locales package in both my user's profile and root's so that the locales would be available to guix-daemon. I insta

bug#36076: Manual should clarify that glibc-utf8-locales is needed by default on foreign distros

Hi Guix, While setting up Guix on a foreign distribution (CentOS 7), I elected to use the full glibc-locales while following section 2.6.1 of the manual for application setup. I installed the glibc-locales package in both my user's profile and root's so that the locales would be available to g

bug#36074: [PATCH] etc: guix-daemon.service.in: fix GUIX_LOCPATH quoting

etc/guix-daemon.service.in: Move the GUIX_LOCPATH environment varialbe name inside the quotes are required in systemd unit files. --- etc/guix-daemon.service.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/etc/guix-daemon.service.in b/etc/guix-daemon.service.in index 7b20a9

bug#36074: Incorrect quoting of GUIX_LOCPATH environment variable in guix-daemon.service

I wrote more about this on help-guix@ https://lists.gnu.org/archive/html/help-guix/2019-06/msg00024.html

bug#36074: Incorrect quoting of GUIX_LOCPATH environment variable in guix-daemon.service

Hi Guix, Based on my experience setting up Guix on a CentOS 7 foreign distribution, if quoted, the variable name in a systemd unit Environment definition should be inside the quotes. I didn't not find definitive documentation stating this, but all the examples show it this way. If the value is

bug#35919: recutils package does not install emacs rec-mode

On Tue, 28 May 2019, Ludovic Courtès wrote: That must be a regression. Could you check how this can be fixed? Sure, I can take a look and see if I can spot the problem. Best, Jack

bug#35919: recutils package does not install emacs rec-mode

Hello Guix, Emacs is listed as a native imput of the recutils package, but the emacs rec-mode is not install (it is found in the etc directory of the source). Best, Jack jackhill@alperton ~$ guix describe Generation 33 May 23 2019 21:23:03(current) guix e26d628 repository URL: htt

<    1   2   3   >