bug#47007: dcb640f02b broke guix environment --container

Am Tue, Mar 09, 2021 at 10:00:30PM +0100 schrieb Ludovic Courtès: > Here’s a more sensible patch for you to try. This time it should > correctly determine the necessary mount flags based on statfs(2) info. > Could you apply it and report back? This one works like a charm, thanks a lot! Andreas

bug#47007: dcb640f02b broke guix environment --container

Hello, incidentally I stumbled upon the same problem as Jelle today. Am Tue, Mar 09, 2021 at 05:17:10PM +0100 schrieb Ludovic Courtès: > Could you try the attached patch? It raises an error: $ ./pre-inst-env guix environment -C --ad-hoc coreutils Backtrace: In ice-9/boot-9.scm: 1736:10 17

bug#46292: Reopen

This has become a duplicate of https://issues.guix.gnu.org/47007 , closing it again. Andreas

bug#46292: Reopen

Hello, I notice the exact same problem still on a Guix System (!) freshly reconfigured with commit b1cabedd28b92324259875fc52ca5d52d411a026, so the kernel is 5.11.4-gnu. In my case /tmp is just an ordinary subdirectory of /, which itself is LUKS encrypted and mounted from /dev/mapper/cryptroot.

bug#46829: Fresh install of 1.2.0 can't guix pull

Am Mon, Mar 01, 2021 at 11:19:08AM +0100 schrieb Ludovic Courtès: > That’s on an installation without ‘nss-certs’ in the system profile, > right? Yes, I installed nss-certs into the profiles from which I wanted to do the "guix pull". Andreas

bug#31719: Chains of dependencies getting longer

Hello, Am Mon, Mar 01, 2021 at 11:04:02AM +0100 schrieb Ludovic Courtès: > Andreas Enge skribis: > > trying a "guix build openjdk", I see this: > > 2136.0 MB would be downloaded ... > >/gnu/store/ymyvcc0871lwbnkv5acf5lldv0ahm5z1-open

bug#46829: Fresh install of 1.2.0 can't guix pull

Am Sun, Feb 28, 2021 at 10:27:02AM + schrieb Christopher Baines: > This is probably possible to work around by doing: > guix pull --url=http://git.savannah.gnu.org/git/guix.git This works, thanks for sharing! But it prints a nonsensical warning message: Updating channel 'guix' from Git

bug#46829: Fresh install of 1.2.0 can't guix pull

Am Sun, Feb 28, 2021 at 10:27:02AM + schrieb Christopher Baines: > I believe there's TLS issues with pulling for the current 1.2.0 release. > Updating channel 'guix' from Git repository at > 'https://git.savannah.gnu.org/git/guix.git'... > guix pull: error: Git error: the SSL certificate is

bug#31719: Chains of dependencies getting longer

Hello, trying a "guix build openjdk", I see this: 2136.0 MB would be downloaded: /gnu/store/243algr6h60j46spn5dqhjc4mhkd0a0p-libelf-0.8.13 /gnu/store/ymyvcc0871lwbnkv5acf5lldv0ahm5z1-openjdk-9.181-jdk /gnu/store/3hb80r2l48ix8pq2kvcsr1i9aj76d681-openjdk-9.181

bug#42162: gforge.inria.fr to be taken off-line in Dec. 2020

Am Wed, Jan 13, 2021 at 11:39:19AM +0100 schrieb Ludovic Courtès: > ISL, MPFI, and GMP-ECM haven’t migrated, it seems. gmp-ecm has migrated to gitlab.inria.fr; I just pushed a commit with an updated URI. Besides the automatically created gitlab releases with git snapshots, the maintainer also

bug#42162: gforge.inria.fr to be taken off-line in Dec. 2020

Hello, Am Wed, Jan 13, 2021 at 11:39:19AM +0100 schrieb Ludovic Courtès: > ISL, MPFI, and GMP-ECM haven’t migrated, it seems. CMH is now at > but without its tarballs. > > Andreas, do you happen to know about the status of these? For CMH, the tarballs are

bug#43618: Problem building disk-image with guix from git

On Mon, Oct 05, 2020 at 10:12:00AM -0700, Fredrik Salomonsson wrote: > It works > fine now when I launched the `guix-daemon` in the correct environment. Closing the bug then by sending a message to 43618-d...@debbugs.gnu.org. Andreas

bug#43773: [PATCH] offload: Improve load normalization and configurability.

Hello Maxim, On Sat, Oct 03, 2020 at 11:21:12PM -0400, Maxim Cournoyer wrote: > Fixes . > > The computed normalized load was previously obtained by dividing the load > average as found in /proc/loadavg by the number of parallel builds defined for > a build

bug#43579: g++ does not provide std::fegetround

Hello, On Thu, Oct 01, 2020 at 09:39:35PM -0500, Brett Gilio wrote: > >> The following test file round.cpp does not compile with our g++-10.2.0: > >> #include > >> int main () { > >>return std::fegetround (); > >> } > > > > Could you provide detailed steps to reproduce it? well, just put

bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot

Hello, On Wed, Sep 30, 2020 at 01:27:54PM +0200, Danny Milosavljevic wrote: > At least I don't. I don't even have a homedir on dover.guix.info, so I cannot > run guix pull, guix describe, or really anything that is interesting on there. this is a problem I have now seen at least three times, so

bug#43720: Reconfiguring does not create home directories

Hello, when adding new users to a Guix system configuration and reconfiguring, their home directories are not created. It has happened a few times when creating accounts for interns on bayfront, and it has happened right now with Danny's account on dover. This behaviour seems to contradict the

bug#26604: documentation: pdf generation is broken

Hello, On Mon, Sep 28, 2020 at 09:57:43PM +0200, zimoun wrote: > [env]$ make doc/guix.pdf try this instead: make V=1 pdf which will print what happens. I have the monolithic texlive package in my profile and building the pdf "almost worked": ... doc/images/coreutils-size-map.png> !pdfTeX

bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot

Hello Danny, On Sat, Sep 26, 2020 at 12:53:20PM +0200, Danny Milosavljevic wrote: > I'd like to test what happens if one builds json-c on an aarch64 host > for i686. > Could we enable qemu-binfmt for i686 on an aarch64 host for me to test it? > One machine is enough--I'd just run > guix

bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot

Hello Danny, On Sat, Sep 26, 2020 at 12:53:20PM +0200, Danny Milosavljevic wrote: > Could we enable qemu-binfmt for i686 on an aarch64 host for me to test it? I am working (or rather, the machine is compiling) to set it up on dover. When it is finished, I will keep you updated (it may take a

bug#43618: Problem building disk-image with guix from git

On Fri, Sep 25, 2020 at 06:04:53PM -0700, Fredrik Salomonsson wrote: > Please close this issue. > Sent it to the wrong mailing list... Done, by sending a message to the address in cc. Andreas

bug#43487: icecat store names in user profiles break bundled addons

Hello Mark! On Mon, Sep 21, 2020 at 01:53:36PM -0400, Mark H Weaver wrote: > Agreed. When I wrote of implementing an "automatic refresh", I meant > something very different and much more limited than what "Refresh > IceCat" in does: I meant merely to refresh the embedded > store names in the

bug#43579: g++ does not provide std::fegetround

On Wed, Sep 23, 2020 at 10:05:43PM +0200, Andreas Enge wrote: > It looks very similar indeed. But then the fix given there has not fixed > my problem, which occurs in a current gcc-toolchain. My impression is that the root cause is the same one, that we are somehow misconfiguring our gcc

bug#43579: g++ does not provide std::fegetround

On Wed, Sep 23, 2020 at 09:03:54PM +0200, Ricardo Wurmus wrote: > Is this perhaps related to https://issues.guix.gnu.org/42392 ? It looks very similar indeed. But then the fix given there has not fixed my problem, which occurs in a current gcc-toolchain. Andreas

bug#43579: g++ does not provide std::fegetround

On Wed, Sep 23, 2020 at 06:21:21PM +0200, Andreas Enge wrote: > Now it would be interesting to have a look at config.log for gcc... I did so with gcc-10.2.0 and executed ./configure in the subdirectory libstdc++-v3. The relevant part of config.log is this: configure:16462: checking for ISO

bug#43579: g++ does not provide std::fegetround

Hello, this report is related to https://github.com/fplll/fplll/issues/444 The following test file round.cpp does not compile with our g++-10.2.0: #include int main () { return std::fegetround (); } Compilation (also when adding "--std=c++11") prints the error: round.cpp: In function

bug#43487: icecat store names in user profiles break bundled addons

Hello Mark, On Fri, Sep 18, 2020 at 02:48:34AM -0400, Mark H Weaver wrote: > To temporarily fix these problems while retaining most of your user > data, one option is to press the "Refresh IceCat…" button in > . Choosing this option will reset all your preferences > and addons to the IceCat

bug#32548: Cuirass: Performance monitoring

On Mon, Sep 14, 2020 at 03:34:17PM +0200, Mathieu Othacehe wrote: > I just pushed support for computing and displaying metrics in Cuirass. I > started with two metrics: > * Builds per day > * Average evaluation speed per specification. > Those metrics can now be seen at: >

bug#43232: [PATCH 2/2] gnu: jack2: 'declare-for-int phase no longer required.

On Tue, Sep 15, 2020 at 01:37:05AM -0700, Mike Rosset wrote: > Apologies, I just wanted to keep a series for posterity which normally > I'm terrible at. I should have mentioned you could just squash them. No problem, it is just less work for me to apply just one patch :) I pushed the commit,

bug#43232: [PATCH 2/2] gnu: jack2: 'declare-for-int phase no longer required.

Hello Mike, On Tue, Sep 15, 2020 at 12:48:02AM -0700, Mike Rosset wrote: > * gnu/packages/audio.scm (jack2): remove 'declare-for-int phase. > [arguements]: phases 'declare-for-int has been removed. since package now > builds. I am getting a bit lost; it looks like this patch has to be applied on

bug#43274: fdisk fails to build on armhf

Hello Timotej, On Tue, Sep 08, 2020 at 07:50:58PM +0200, Timotej Lazar wrote: > genimage tests fail on arm64 due to differently signed char. The fix¹ > is in upstream master but has not been released yet. Maybe we can add > it to the current Guix package until then? > ¹

bug#43151: Resolve Calibre run-time dependency

Hello, On Mon, Sep 07, 2020 at 06:15:15PM +1000, Brendan Tildesley wrote: > Your patch also works I think but it will wrap the programs twice, so > you will get calibre, .calibre-real, and ..calibre-real-real, etc for > every program, which seems ugly. My patch reproduces the same PYTHONPATH >

bug#43274: fdisk fails to build on armhf

On Tue, Sep 08, 2020 at 05:47:53PM +0200, Andreas Enge wrote: > The next step would be to check newer releases (12 and 13) of genimage. > Has it actually ever been built on the arm architecture? I tried 12 and 13, but already on x86_64 the test FAIL: test/basic-images.test 7 - mke2fs

bug#43274: fdisk fails to build on armhf

On Tue, Sep 08, 2020 at 03:12:03PM +0200, Andreas Enge wrote: > So there does not even seem to be a test that relies on fdisk. Looking at the tests, they do call "fdisk" and "sfdisk", but these come from the util-linux package. The fdisk package only provides "gn

bug#43274: fdisk fails to build on armhf

Here is what happens when I drop fdisk from native-inputs of genimage: starting phase `check' make --no-print-directory check-TESTS PASS: test/basic-images.test 1 - cpio SKIP: test/basic-images.test 2 # SKIP cramfs (missing mkcramfs) ... PASS: test/basic-images.test 20 - fit

bug#43274: fdisk fails to build on armhf

The same two tests also fail on an armhf machine. Andreas

bug#43274: fdisk fails to build on armhf

Hello, I am trying to build an armhf disk image on an aarch64 machine. The build fails in this order: genimage requires fdisk fdisk requires guile-1.8.8 (!) guile-1.8.8 fails two of its 16 tests: ERROR: Value out of range -9223372036854775808 to 9223372036854775807: -9223372036854775808 FAIL:

bug#43232: jack2 fails to build on aarch64

Updating jack2 to 1.9.14 does not solve the problem. Andreas

bug#43232: jack2 fails to build on aarch64

The error message is: [228/274] Compiling example-clients/simdtests.cpp ... [243/274] Linking build/example-clients/jack_simdtests ... ld: example-clients/simdtests.cpp.28.o: undefined reference to symbol '__gxx_personality_v0@@CXXABI_1.3' ld:

bug#43151: Calibre ebook-viewer requires QtWebEngine

(cc-ing this and only this bug, the other one seems to have diverged towards css and typescript) On Fri, Sep 04, 2020 at 07:53:02PM +1000, Brendan Tildesley wrote: > > I did not realise there was already an open ticket for updating calibre, > > thanks for pointing it out. Indeed I do not think we

bug#26303: Closing

Closing as unreproducible without a provided test file. There is a good chance that this is related to a freedom problem with unrar anyway. Andreas

bug#41196: Update

Closing as a duplicate of 25667. Andreas

bug#41196: Update

Hello, the same problem happened to me right now, but it is not related to any versions or updates in Guix. In fact, I just did an aggressive "guix gc", which removed the referenced exo version from the store. The path is actually stored in my

bug#34207: Closing

grantlee-5.2.0 is served as a substitute, so the problem is apparently solved. Closing. Andreas

bug#33559: Closing

We are at icecat-68 now, which does build. Closing. Andreas

bug#33312: Closing

This version is so old that the bug report does not seem relevant any more. Please open a new bug when "make check" fails. Andreas

bug#32522: Closing

qtwebkit-5.212.0 is now available as a substitute, closing the bug. Andreas

bug#43221: webkitgtk fails to build on aarch64

On Sat, Sep 05, 2020 at 01:14:06PM -0700, Mike Rosset wrote: > It's working now on aarch64-linux. I'm using guix describe @ > 81ea278e05986f9ccee078bd00d4d7fc309dd19c at least it's serving > substitutes. > > Think we can close this now. Thanks for the confirmation, closing it. Andreas

bug#43221: webkitgtk fails to build on aarch64

Hello, On Sat, Sep 05, 2020 at 04:18:47PM +0100, Pierre Langlois wrote: > That sounds familiar, I think I hit this issue a few weeks > back. But at the moment, it seems the CI has successfully built php for > aarch64 https://ci.guix.gnu.org/build/3166798/details from what I understood, the

bug#43220: Eog not starting

Hello, when trying to run eog, I get the following message: (eog:4813): GLib-GIO-ERROR **: 11:49:04.247: Settings schema 'org.gnome.desktop.thumbnailers' is not installed Trace/breakpoint trap Comments on help-guix in this thread:

bug#35210: Error building linux-libre on Overdrive 1000

Hello, On Tue, Apr 09, 2019 at 09:37:29PM +0200, Tobias Geerinckx-Rice wrote: > Andreas Enge wrote: > > I confirm after just trying to reconfigure, with commit > > 36dbad3858ca4229e9ec319bd4983fca7835067d. > > Cc-ing the bug tracker. > Thanks! I wasn't expecting to hit an

bug#43112: hedgewars 1.0.0 fails to build

Hello, On Sun, Aug 30, 2020 at 01:23:37PM +, bdju via Bug reports for GNU Guix wrote: > build log here: > http://ix.io/2vGD > > running guix (GNU Guix) a6b72a0f2b02f27c44c28d32ec26fc8188ee61b8 I also gave it a try, seeing that the build log does not show any error. With "guix build -K", I

bug#43151: Calibre ebook-viewer requires QtWebEngine

On Tue, Sep 01, 2020 at 12:03:47PM +0200, Andreas Enge wrote: > The following works: > QTWEBENGINEPROCESS_PATH=`guix build > qtwebengine`/lib/qt5/libexec/QtWebEngineProcess ebook-viewer > > Do we need to set a search path in qtwebengine? Well, no, since qtwebengine is not act

bug#43151: Calibre ebook-viewer requires QtWebEngine

I did an strace and found the following: 4989 access("/gnu/store/kwx5xihpxmjjf8f8446vn883ank1qcg1-qtbase-5.14.2/lib", F_OK) = 0 4989 access("/gnu/store/kwx5xihpxmjjf8f8446vn883ank1qcg1-qtbase-5.14.2/lib/qt5/libexec/QtWebEngineProcess", F_OK) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)

bug#43151: Calibre ebook-viewer requires QtWebEngine

Hello, when trying to view an epub using ebook-viewer from the calibre package (or by directly clicking on an epub in calibre), the program fails with the message: Could not find QtWebEngineProcess I see that commit d79ec4fd343bc2a72652aa3a4b4ae14bd8df88ac has added python2-pyqtwebengine and

bug#37342: Close

Closing this bug, since by https://lists.gnu.org/archive/html/help-guix/2019-12/msg00140.html the problem is solved. Andreas

bug#36924: Mesa/GDM/XFCE

Hello, On Thu, Sep 12, 2019 at 01:40:09PM +0200, Ludovic Courtès wrote: > Thanks for the report, Andreas! and thanks for the time spent putting me on the good track! > Andreas Enge skribis: > > xfwm4: ../mesa-19.1.4/src/mesa/drivers/dri/i965/intel_mipmap

bug#36924: Mesa/GDM/XFCE

Hello, now it is my turn to experience a problem in this area. I newly installed a machine with the graphical installer of Guix 1.0.1 (where I could use xfce without problem), then I issued a "guix pull" and a "guix system reconfigure". Now logging into XFCE poses problems, which I can reproduce

bug#35625: Python3 Cannot Find Existing Shared Library within guix environment

On Tue, Jun 18, 2019 at 10:34:27AM -0600, Jesse Gibbons wrote: > This issue can be closed. Webkitgtk-2.24 uses gcc 7 which must be a > dependency for packages that use it. Luckily my package works just fine > with the older version of webkitgtk. Done by cc-ing bugnumber-d...@debbugs.gnu.org.

bug#32339: Nix import

So, I just discussed with a Nix expert, Profpatsch. Apparently something changed in nixpkgs a while ago, so that the following code does not work any more: $ export NIX_REMOTE=daemon $ nix-instantiate --eval --strict -A hello nixpkgs/ trace: `types.list` is deprecated; use `types.listOf` instead

bug#32339: Nix import

Sorry, I did not look at the error message well enough, the bug is indeed still the same as reported. Andreas

bug#32339: Nix import

This bug is resolved by following the current documentation and executing export NIX_REMOTE=daemon . However, even then the import fails: $ guix import nix nixpkgs/ hello ;;; SSAX warning: Skipping PI: xml trace: warning: `stdenv.isArm` is deprecated after 18.03. Please use

bug#36180: Problem with non ASCII chars in Libreoffice and zsh on foreign distro

On Thu, Jun 13, 2019 at 02:35:00PM +0200, Andréas Livet wrote: > I just have to add GUIX_LOCPATH to ~/.xsessionrc and it works for LibreOffice > AND zsh !! Closing the bug then. Andreas

bug#35942: guix install: environment variable message is very confusing

Hello, On Thu, May 30, 2019 at 09:07:30AM +0200, Ricardo Wurmus wrote: > I was in favour of *replacing* the message with the suggestion to run >export GUIX_PROFILE=/this/profile >source $GUIX_PROFILE/etc/profile > because it usually does the right thing. I think this was the conclusion

bug#35806: Login passwords incorrect on some newly installed 1.0.1 systems

So closing it by cc-ing 35806-d...@debbugs.gnu.org. Andreas

bug#35904: Rx 580 and Guix

Closing this report, as it does not constitute a bug. help-g...@gnu.org would be a more appropriate channel to ask for help. Thanks, Andreas

bug#35178: Agda doesn't build

So closing this bug. Thanks, Andreas

bug#35529: libdrm fails to build on armhf-linux

On Fri, May 03, 2019 at 07:29:03AM +0200, Ricardo Wurmus wrote: > > Both build attempts were made on hydra-slave2, which is a Wandboard Quad > > based on the Freescale i.MX6 SOC. > This has built fine on berlin. We have a completed build for >

bug#35210: Error building linux-libre on Overdrive 1000

On Tue, Apr 09, 2019 at 04:37:09PM +0200, Tobias Geerinckx-Rice wrote: > ‘guix system init’ fails for me in the following way on the following > version: > > $ guix describe > Generation 4Apr 08 2019 23:29:08(current) > guix 2afb793 > repository URL:

bug#35016: ranger not fully working

On Wed, Mar 27, 2019 at 12:53:14PM +, Bradley Haggerty wrote: > This issue may be closed. I don't know how to do that myself. Like I am doing right now, by cc-ing bugnumber-d...@debbugs.gnu.org. Thanks, Andreas

bug#34636: "guix refresh" fails

On Mon, Mar 04, 2019 at 11:11:00PM +0100, Ludovic Courtès wrote: > Could it be that you’re running ‘guix refresh’ from a checkout and you > happen to have guile-json@3 instead of guile-json@1 in your Guile load > path? "No" and "yes" :-) But whatever happened in the last two weeks, things work

bug#34333: Docker daemon failing to start on boot

On Fri, Mar 01, 2019 at 09:58:20AM +0100, Allan Adair wrote: > >> > I am however able to execute "sudo herd start > >> > dockerd" after booting > > I'm not so sure. One thing that I am unable to do is "herd start > dockerd". You mean, you are not able to start it via sudo su - herd start

bug#34677: solved

It is "-done", not "-closed" :-) Andreas

bug#34333: Docker daemon failing to start on boot

On Wed, Feb 27, 2019 at 04:53:27PM +0100, Björn Höfling wrote: > > After a "guix system reconfigure", it works -- meaning that the > > dockerd service starts. But when booting in the future, the dockerd > > daemon never starts. I am however able to execute "sudo herd start > > dockerd" after

bug#34649: close 34649

Control messages should be sent to the debbugs server, not to a specific bug addess. Closing a bug is simpler, just send a message to xyz-d...@debbugs.gnu.org. Andreas

bug#34636: "guix refresh" fails

Hello, when I run guix refresh (with the latest git commit), the result is an error: Backtrace: 13 (apply-smob/1 #) In ice-9/boot-9.scm: 705:2 12 (call-with-prompt _ _ #) In ice-9/eval.scm: 619:8 11 (_ #(#(#))) In guix/ui.scm: 1654:12 10 (run-guix-command _ . _) In

bug#18483: Dmd tries to initialize my network interface before it become available.

On Tue, Feb 12, 2019 at 07:25:27PM -0500, Leo Famulari wrote: > Is this bug still relevant? Or can we close it? Since no new complaints come in for more than four years, I am closing the bug. Andreas

bug#34580: Service ssh-daemon could not be started

On Wed, Feb 20, 2019 at 05:51:54PM -0500, Leo Famulari wrote: > On Wed, Feb 20, 2019 at 11:48:02PM +0100, Andreas Enge wrote: > > I suppose so. I would be happy to provide further information, but there is > > not much to see in the log files. I grepped for "ssh&q

bug#34580: Service ssh-daemon could not be started

On Wed, Feb 20, 2019 at 05:21:58PM -0500, Leo Famulari wrote: > I wonder if this is another instance of ? I suppose so. I would be happy to provide further information, but there is not much to see in the log files. Andreas

bug#27462: OCaml CVE-2015-8869

On Wed, Feb 20, 2019 at 09:39:20AM +0100, Julien Lepiller wrote: > At this point, we only need it for bap and dependencies. I've added > dependencies for the latest bap commit that work with the latest ocaml, but > they haven't released a new version yet. Can we wait a bit longer? > > Another

bug#34570: Failure to build swig/graphviz

On Tue, Feb 19, 2019 at 10:34:01AM +0100, Andreas Enge wrote: > if there is not an obvious error somewhere, > it might be easier to close the bug report as not reproducible or non-deter- > ministic. Doing so. Andreas

bug#32253: Fixed

The bug has apparently been fixed in the meantime, I cannot reproduce it any more. Andreas

bug#19749: Progress

Hello, this bug dates from a time where it was still almost realistic to reach zero non-building packages... Should we close it, since mips has been removed from the release architectures? Andreas

bug#18221: Close

The bug stricto sensu has been fixed by a "supported systems" clause. Since in more than 4 years nobody seems to have missed the package on other architectures, I am closing the bug for now. Andreas

bug#17117: Close

There have been so many changes since this bug was opened that it is not meaningful any more, and it was in any case more of "wishlist type". Closing it. Andreas

bug#32238: Close

The problem was corrected at some point in time without reference to the bug. The calibre package now builds and works. Andreas

bug#22835: Close

This can probably be closed, as nobody really remembers any more what it is about. Andreas

bug#27462: OCaml CVE-2015-8869

On Thu, Jan 31, 2019 at 06:30:27PM +0100, Julien Lepiller wrote: > I still care about ocaml-4.02, but I could probably update it to ocaml-4.04 > without breaking dependents. Commits 2e125ece093ef842ca017ffb146cbc5fa33f2f75 and 4982c0c98deecea0d4f69f14ea28cab53b5f2123 remove ocaml@4.01, pplacer

bug#34580: Service ssh-daemon could not be started

Hello, twice in a row at work (on harbourfront) and now twice in a row at home (on dover) I am in a situation where sshd does not start on Guix machines. Networking is available (the machines can be pinged), and I have to log in via a console and execute "herd start ssh-daemon" by hand. Here is

bug#34573: Backtrace of guix pull failed

Bonjour Vincent, On Tue, Feb 19, 2019 at 10:55:58AM +0100, Vincent Rouvreau wrote: > And guix pull failed : > > guix package -i python python-numpy python-conda > eval `guix package --search-paths=prefix` so the first two commands succeeded? > guix pull > Backtrace: > In

bug#34531: Guix profile fails on Overdrive 1000

On Tue, Feb 19, 2019 at 02:23:23PM +0100, Ricardo Wurmus wrote: > Guix pull needs “guile-git”, and “guile-git” needs “libgit2”, which > needs “python-wrapper”. To remove the need for Python in “guix pull” we > would need to build libgit2 without Python. I don’t know if anyone has > investigated

bug#34570: Failure to build swig/graphviz

On Tue, Feb 19, 2019 at 10:16:32AM +0100, Danny Milosavljevic wrote: > I think that the test suite contains multiple sets of tests and and earlier > set > failed (the 514 perl5 tests apparently didn't fail; the warning shouldn't > make tests fail anyway). What's before what you posted in the

bug#34570: Failure to build swig/graphviz

Hello, the following happens when using "guix pull -n" on my Overdrive with Guix 0.16.0. So maybe it has been solved in the meantime. When building swig-3.0.12 (for whatever reason...), the build fails with the following error during the check phase. Actually there are two errors; I suppose the

bug#34531: Guix profile fails on Overdrive 1000

Hello Marius, thanks a lot for your quick and helpful reply! On Mon, Feb 18, 2019 at 09:49:10PM +0100, Marius Bakke wrote: > The Python contained within this Guix snapshot has a known bug that > makes it leak memory on newer kernels. The Guix commit that works > around it is

bug#34531: Guix profile fails on Overdrive 1000

Hello, on a newly installed Overdrive 1000 machine with 8 GB of memory, I am trying guix pull -n This results in Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... Building from this channel: guix https://git.savannah.gnu.org/git/guix.git

bug#34431: Qt fails to build

On Tue, Feb 12, 2019 at 05:59:24PM +0100, Ricardo Wurmus wrote: > > Danny Milosavljevic skribis: > >> Possible fix https://672856.bugs.gentoo.org/attachment.cgi?id=557978 The patch makes qtbase build on my laptop, so I pushed it as commit 69c15ad8a46c8e5f319a73ee5891bcd1bf0600c5. The bug can

bug#34431: Qt fails to build

On Mon, Feb 11, 2019 at 04:27:38PM +0100, Andreas Enge wrote: > It happens on my laptop, with kernel 4.9.0. But I thought it also happens > on bayfront (kernel 4.19.1), which offloads to harbourfront (kernel 4.19.8). > I will try the latter two again. Actually I did not remember wel

bug#34431: Qt fails to build

Hello Danny, On Mon, Feb 11, 2019 at 12:41:45PM +0100, Danny Milosavljevic wrote: > maybe https://bugs.gentoo.org/672856 is related. > They say: > >/usr/lib/libQt5Core.so.5.11.3: ELF 64-bit LSB pie executable, x86-64, > >version 1 (GNU/Linux), dynamically linked, interpreter >

bug#34431: Qt fails to build

Hello, qt currently fails to build for me. $ guix describe Generation 11 10. Februar 2019 09:32:33 (aktuell) guix 50a93ad Repository-URL: https://git.savannah.gnu.org/git/guix.git Commit: 50a93adc05b611836e740c4b55571890f4c6770a $ guix build qtbase ...

bug#27462: OCaml CVE-2015-8869

On Thu, Jan 31, 2019 at 05:57:03PM +0100, Andreas Enge wrote: > Are people using the software I suppose not, because one of its dependencies currently does not build: ... phase `ocaml-findlib-environment' succeeded after 0.0 seconds starting phase `configure' build directory: "/tmp/gu

bug#27462: OCaml CVE-2015-8869

Hello, this bug has been open for quite a while, and the development of pplacer seems to be stalled, with the latest commit in May 2018, and no reaction whatsoever to Ben's bug report https://github.com/matsen/pplacer/issues/354 How should we continue? Are people using the software, or should

<    1   2   3   4   5   >