bug#25689: gnome-shell segfaults
2017-02-11 15:31 GMT+01:00 ng0 : > So, I am not 100% sure if I encouter hardware failures or software > failures here. But I need to solve wether this is a GNOME bug to exclude > or include the hardware failure. > > The following is the log output of a session with SSDM where I > succesfully log into "GNOME with Xorg" and launch the GNOME-Terminal > after I logged into GNOME. > > The visual side of the log can be described like this: I can see how > the terminal application opens, but just a milisecond after it's ready I > see the window decoration disappearing, content of the application > stays, GNOME session crashes, on a dark scree I see for a moment: > > vmunix: [ 226.579414] nouveau :01:00.0: DRM: 0xD4A7: Parsing digital > output script table > > and I get thrown back to the log in screen of SDDM. > > Occasionally gnome-terminal or some other gnome part would crash my > gnome session when I still used SLIM. > > This is on commit 883aab6462c49d4f4846a6f22168325e70227663 > but has been happening for a very long time before this commit. > I use the Gnome terminal all the time and I can't confirm your experience CAVEATS: 1) I don't know whether I'm using SSDM or SLIM. I just took the basic desktop conf file when I installed 2) this is my video card ~$ lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) ~$ egrep -i " connected|card detect|primary dev|Setting driver" /var/log/Xorg.0.log [ 7.760] (II) intel(0): Using Kernel Mode Setting driver: i915, version 1.6.0 20160919
bug#25689: gnome-shell segfaults
On 17-03-03 10:02:52, Catonano wrote: > 2017-02-11 15:31 GMT+01:00 ng0 : > > > So, I am not 100% sure if I encouter hardware failures or software > > failures here. But I need to solve wether this is a GNOME bug to exclude > > or include the hardware failure. > > > > The following is the log output of a session with SSDM where I > > succesfully log into "GNOME with Xorg" and launch the GNOME-Terminal > > after I logged into GNOME. > > > > The visual side of the log can be described like this: I can see how > > the terminal application opens, but just a milisecond after it's ready I > > see the window decoration disappearing, content of the application > > stays, GNOME session crashes, on a dark scree I see for a moment: > > > > vmunix: [ 226.579414] nouveau :01:00.0: DRM: 0xD4A7: Parsing digital > > output script table > > > > and I get thrown back to the log in screen of SDDM. > > > > Occasionally gnome-terminal or some other gnome part would crash my > > gnome session when I still used SLIM. > > > > This is on commit 883aab6462c49d4f4846a6f22168325e70227663 > > but has been happening for a very long time before this commit. > > > > I use the Gnome terminal all the time and I can't confirm your > experience > > CAVEATS: > > 1) I don't know whether I'm using SSDM or SLIM. I just took the basic > desktop conf file when I installed That's SLIM then. > 2) this is my video card > > ~$ lspci | grep VGA > 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core > processor Graphics Controller (rev 09) > > ~$ egrep -i " connected|card detect|primary dev|Setting driver" > /var/log/Xorg.0.log > [ 7.760] (II) intel(0): Using Kernel Mode Setting driver: i915, version > 1.6.0 20160919 Yes, I can confirm this too, as this only happens with AT and NVidia cards for me. The one in the system I tested is supported well enough to be slow in GNOME but can play back videos without lagging. This is due to the firmware in linux-libre not offering all the features the blob variant would provide. I was not able to reproduce it with anything other than GNOME.
bug#25688: services: ssh-daemon quits too early
On 17-03-02 22:20:44, ng0 wrote: > On 17-03-02 16:58:35, Leo Famulari wrote: > > On Sat, Feb 11, 2017 at 03:00:13PM +, ng0 wrote: > > > This is the ~120 lines of today. It reminded me of the real issue, which > > > is dbus could not be started, which very likely could be the reason for > > > the GNOME session crashing bug I reported. > > > > Are you still having this problem (dbus-system could not be started)? > > I've recently started to d othe system from 0 again to rule out > offloading issues, but ssh-daemon started failing again. I'll look into > the issue on the weekend. > > > I can confirm this continues to be a problem on the new system, repeatedly: Service user-homes could not be started. The same for ssh-daemon, but now dbus-system can be started and the problem could therefore be user-homes.
bug#25894: guix pull error
hello, I use GNOME on a laptop with NVIDIA graphic card, sometimes GNOME stops working; graphic mode and console do not respond!. Then proceed to turn it off with the keyboard button, since I have no option!. This error is due to the graphics card. El Thu, 2 Mar 2017 17:17:39 -0500 Leo Famulari escribi?: On Wed, Mar 01, 2017 at 10:48:27PM -0600, ren...@openmailbox.org wrote: > Hello, > in my situation the error was fixed with the command: > 'guix gc --verify=contents' > > The possible cause that generate the error is shutdown the machine > unexpectedly. > Aditional my platform is Linux x86_64 with GuixSD version > (20170302.02). It would be interesting to figure out exactly what happened. It would be better if Guix was not vulnerable to power loss. True. But maybe it was not that. I still cannot repair.
bug#25952: offloading: empty machines file leads to error
I have misplaced my log for this, but it is easy to reproduce: configure offloading on master and build-machine, comment the entire content of the file which holds the build-machines, run "guix build hello" and see the error. This should even work when you haven't configured offloading, just with an empty machines file.
bug#25953: [Mesa] Very low Gallium performance compared to Trisquel
This came up in a help-guix thread, and Ricardo Wurmus asked me to post here requesting that Mesa be built with LLVM to improve Gallium's performance. The original post is here: https://lists.gnu.org/archive/html/help-guix/2017-02/msg00141.html but in short, when running GuixSD on my system, Gnome is unusably slow, and while LXDE is usable, trying to play even 480p videos results in a slideshow rather than a video. On Trisquel though, even though it's also blobless and using Gallium, the performance is vastly better, and even HD videos play fine. I'm not really familiar with stuff this deep into the system, so if there's any extra info you all need then just let me know and I'll be happy to provide it. Anyway, thanks for your time, and all the work you all are doing. Matthew F. Brooks
bug#25177: python-tests: python-oslosphinx fixed. Please evaluate.
Leo Famulari writes: >> Anyway, this bug has been a massive pain and I'm going to merge it >> tomorrow so I can get on with life. The 'master' jobset should be >> started afterwards; perhaps you can merge and start the evaluation? > > Okay, let me know when you push the merge and I'll start the evaluation. Merged! Closing this bug. Hooray! signature.asc Description: PGP signature
bug#25894: another guix system reconfigure /etc/config.scm
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0% substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0% substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0% substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0% substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 0.0%Backtrace: substitute: In ice-9/boot-9.scm: substitute: 160: 9 [catch #t # ...] substitute: In unknown file: substitute:?: 8 [apply-smob/1 #] substitute: In ice-9/boot-9.scm: substitute: 66: 7 [call-with-prompt prompt0 ...] substitute: In ice-9/eval.scm: substitute: 432: 6 [eval # #] substitute: In ice-9/boot-9.scm: substitute: 2404: 5 [save-module-excursion #] substitute: 4056: 4 [#] substitute: 1727: 3 [%start-stack load-stack ...] substitute: 1732: 2 [#] substitute: In unknown file: substitute:?: 1 [primitive-load "/gnu/store/c77gfhkmnwjvgmnsafjxf1g9kkpiilbh-guix-0.12.0-4.d9da/bin/.guix-real"] substitute: In guix/ui.scm: substitute: 1228: 0 [run-guix-command substitute "--query"] substitute: substitute: guix/ui.scm:1228:8: In procedure run-guix-command: substitute: guix/ui.scm:1228:8: Bad Read-Header-Line header: # substitute: guix system: error: build failed: substituter `substitute' died unexpectedly -- Saluton, Quiliro 0987631031
bug#25177: python-tests: python-oslosphinx fixed. Please evaluate.
On Fri, Mar 03, 2017 at 05:52:34PM +0100, Marius Bakke wrote: > Leo Famulari writes: > > >> Anyway, this bug has been a massive pain and I'm going to merge it > >> tomorrow so I can get on with life. The 'master' jobset should be > >> started afterwards; perhaps you can merge and start the evaluation? > > > > Okay, let me know when you push the merge and I'll start the evaluation. > > Merged! Closing this bug. Hooray! Thank you for working on this! signature.asc Description: PGP signature
bug#25953: [Mesa] Very low Gallium performance compared to Trisquel
On Fri, Mar 03, 2017 at 02:04:14AM -0600, Matthew Brooks wrote: > This came up in a help-guix thread, and Ricardo Wurmus asked me to > post here requesting that Mesa be built with LLVM to improve Gallium's > performance. > > The original post is here: > https://lists.gnu.org/archive/html/help-guix/2017-02/msg00141.html > but in short, when running GuixSD on my system, Gnome is unusably > slow, and while LXDE is usable, trying to play even 480p videos > results in a slideshow rather than a video. > On Trisquel though, even though it's also blobless and using Gallium, > the performance is vastly better, and even HD videos play fine. > > I'm not really familiar with stuff this deep into the system, so if > there's any extra info you all need then just let me know and I'll be > happy to provide it. I used to use GuixSD's GNOME on my Thinkpad x200s but, at some point, it started to have the problem you describe. I decided to stop using GNOME instead of investigating the bug because I had no idea where to start looking. But if I can help change some packages and test the changes, please let me know how.
bug#25953: [Mesa] Very low Gallium performance compared to Trisquel
Leo Famulari writes: > On Fri, Mar 03, 2017 at 02:04:14AM -0600, Matthew Brooks wrote: >> This came up in a help-guix thread, and Ricardo Wurmus asked me to >> post here requesting that Mesa be built with LLVM to improve Gallium's >> performance. >> >> The original post is here: >> https://lists.gnu.org/archive/html/help-guix/2017-02/msg00141.html >> but in short, when running GuixSD on my system, Gnome is unusably >> slow, and while LXDE is usable, trying to play even 480p videos >> results in a slideshow rather than a video. >> On Trisquel though, even though it's also blobless and using Gallium, >> the performance is vastly better, and even HD videos play fine. >> >> I'm not really familiar with stuff this deep into the system, so if >> there's any extra info you all need then just let me know and I'll be >> happy to provide it. > > I used to use GuixSD's GNOME on my Thinkpad x200s but, at some point, it > started to have the problem you describe. I decided to stop using GNOME > instead of investigating the bug because I had no idea where to start > looking. > > But if I can help change some packages and test the changes, please let > me know how. What are your hardware specs? For testing, you could try building "mesa" with "--enable-gallium-llvm" and maybe "--enable-llvm-shared-libs". It could be interesting to see how Trisquel builds mesa. signature.asc Description: PGP signature
bug#25894: another guix system reconfigure /etc/config.scm
When using the same process with a good bandwidth connection, there is no problem with guix system reconfigure /etc/config.scm or with guix pull or with sending emails in Claws-Mail
bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks
Our gitolite package currently creates all (including gitolite-admin.git) git repositories with references to "/usr/bin/perl" as shebang, which makes it completely useless on serverside. Given that the server side in the case of a gitolite from Guix runs an environment where you will not run perl from /usr/bin/, you will have to change all hooks manually currently. When you install perl into the profile of the user which hosts the repositories and change the shebangs, gitolite can be used.
bug#25957: Acknowledgement (gitolite broken: created repositories keep references to /usr/bin for hooks)
What makes this worse, with every update (push) of gitolite-admin repository the shebang of "hooks/update" is reset. Other repositories seem to keep changes in the hooks shebangs so far.
bug#25958: missing cursor icons in Gnome
If you try to drag an application to the floating bar on the left in Gnome, the Gnome Shell will crash, it will be started again and you will have to login again I first reported this here https://lists.gnu.org/archive/html/help-guix/2017-02/msg00128.html Installing adwaita-icon-theme didn't help
bug#25894: guix system reconfigure /etc/config.scm ... still poses errors
With a good bandwidth connection, errors are none in guix pull and do not pop up immediately in guix system reconfigure /etc/config.scm But finally at the end, I get these failures: FAILURES: --ion-eager /tmp/guix-build-mozjs-24.2.0.drv-0/mozjs-24.2.0/js/src/jit-test/tests/basic/bug698584.js --no-baseline --no-ion /tmp/guix-build-mozjs-24.2.0.drv-0/mozjs-24.2.0/js/src/jit-test/tests/basic/bug698584.js --baseline-eager --no-ti --no-fpu /tmp/guix-build-mozjs-24.2.0.drv-0/mozjs-24.2.0/js/src/jit-test/tests/basic/bug698584.js --baseline-eager /tmp/guix-build-mozjs-24.2.0.drv-0/mozjs-24.2.0/js/src/jit-test/tests/basic/bug839215.js --ion-eager /tmp/guix-build-mozjs-24.2.0.drv-0/mozjs-24.2.0/js/src/jit-test/tests/basic/bug839215.js --no-baseline --no-ion /tmp/guix-build-mozjs-24.2.0.drv-0/mozjs-24.2.0/js/src/jit-test/tests/basic/bug839215.js --baseline-eager --no-ti --no-fpu /tmp/guix-build-mozjs-24.2.0.drv-0/mozjs-24.2.0/js/src/jit-test/tests/basic/bug839215.js --no-baseline --no-ion --no-ti /tmp/guix-build-mozjs-24.2.0.drv-0/mozjs-24.2.0/js/src/jit-test/tests/basic/bug839215.js TIMEOUTS: make: *** [Makefile:312: check-jit-test] Error 2 phase `check' failed after 1024.7 seconds builder for `/gnu/store/0f5k3zc7l1mhgrjg0avnqy71afrs4ppn-mozjs-24.2.0.drv' failed with exit code 1 cannot build derivation `/gnu/store/3dzc4ngjk4zq8s5b3gxd55miqc8x6cr7-gnome-shell-3.22.2.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/6fv049a0blwg7d62c1xc68hc7czdqb17-gnome-3.22.2.drv': 1 dependencies couldn't be built guix system: error: build failed: build of `/gnu/store/6fv049a0blwg7d62c1xc68hc7czdqb17-gnome-3.22.2.drv' failed I am testing now by re-running guix pull before guix system reconfigure /etc/config.scm -- Saluton, Quiliro 0987631031
bug#25953: Fwd: bug#25953: [Mesa] Very low Gallium performance compared to Trisquel
Forgot to CC this when sending. -- Forwarded message -- From: Matthew Brooks Date: Fri, Mar 3, 2017 at 4:11 PM Subject: Re: bug#25953: [Mesa] Very low Gallium performance compared to Trisquel To: Marius Bakke > What are your hardware specs? I'm using an AMD Phenom II X6 1100T (~3GHz, 6 cores). I've got 16 GB of RAM. My graphics card is an Nvidia Geforce 1060 with 6GB of VRAM. The screen is a 1920x1080 monitor from Asus. > For testing, you could try building "mesa" with "--enable-gallium-llvm" > and maybe "--enable-llvm-shared-libs". How would I do that? I tried making a copy of gl.scm (which contains the definition for the standard mesa package), and stripping out the non-mesa packages and adding those compile flags, but when I did "guix package --install-from-file=./gl.scm", it didn't actually seem to do anything. Before that I also tried "guix package --install mesa --enable-gallium-llvm --enable-llvm-shared-libs", but it (predictably, in hindsight) gave an "unrecognized option" error. Anyway, thanks for your help, and have a nice day!
bug#25894: guix system reconfigure error
I get the following error after guix pull and guix system reconfigure /etc/config.scm FAILURES: --ion-eager /tmp/guix-build-mozjs-24.2.0.drv-0/mozjs-24.2.0/js/src/jit-test/tests/basic/bug698584.js --no-baseline --no-ion /tmp/guix-build-mozjs-24.2.0.drv-0/mozjs-24.2.0/js/src/jit-test/tests/basic/bug698584.js --ion-eager /tmp/guix-build-mozjs-24.2.0.drv-0/mozjs-24.2.0/js/src/jit-test/tests/basic/bug839215.js --baseline-eager /tmp/guix-build-mozjs-24.2.0.drv-0/mozjs-24.2.0/js/src/jit-test/tests/basic/bug839215.js --baseline-eager --no-ti --no-fpu /tmp/guix-build-mozjs-24.2.0.drv-0/mozjs-24.2.0/js/src/jit-test/tests/basic/bug839215.js --no-baseline --no-ion --no-ti /tmp/guix-build-mozjs-24.2.0.drv-0/mozjs-24.2.0/js/src/jit-test/tests/basic/bug839215.js --no-baseline --no-ion /tmp/guix-build-mozjs-24.2.0.drv-0/mozjs-24.2.0/js/src/jit-test/tests/basic/bug839215.js TIMEOUTS: make: *** [Makefile:312: check-jit-test] Error 2 phase `check' failed after 967.0 seconds builder for `/gnu/store/0f5k3zc7l1mhgrjg0avnqy71afrs4ppn-mozjs-24.2.0.drv' failed with exit code 1 cannot build derivation `/gnu/store/3dzc4ngjk4zq8s5b3gxd55miqc8x6cr7-gnome-shell-3.22.2.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/6fv049a0blwg7d62c1xc68hc7czdqb17-gnome-3.22.2.drv': 1 dependencies couldn't be built guix system: error: build failed: build of `/gnu/store/6fv049a0blwg7d62c1xc68hc7czdqb17-gnome-3.22.2.drv' failed -- Saluton, Quiliro 0987631031
bug#25961: Compiling new guix on old guix: 'waitpid' -1 failed unexpectedly: No child processes
Hello! I'm getting this error while trying to compile latest guix master on one of my machines (fortunately, not my main one). I don't know why I'm hitting this error, since I'm not hitting it on my main machine. I'm upgrading from a few months back. I spoke on irc and found that Ricardo had the same issue: paroneayea: I also got this error trying to run “make” paroneayea: it happens on my recording machine (x86_64) that hadn’t been updated in a while, but not on my laptop (also x86_64), which is updated regularly. Here's what I do. I start at the commit I was at (c2662820f359be19262cdd5d564e6a0dddc43281) and run "guix environment guix". Then I do a "git pull && make clean && make" and I get: ;;; Failed to autoload cairo-image-surface-create in (cairo): ;;; ERROR: missing interface for module (cairo) ;;; Failed to autoload cairo-image-surface-create in (cairo): ;;; ERROR: missing interface for module (cairo) ;;; Failed to autoload rsvg-handle-new-from-file in (rsvg): ;;; ERROR: missing interface for module (rsvg) ;;; Failed to autoload cairo-image-surface-create in (cairo): ;;; ERROR: missing interface for module (cairo) ;;; Failed to autoload rsvg-handle-new-from-file in (rsvg): ;;; ERROR: missing interface for module (rsvg) ;;; Failed to autoload cairo-image-surface-create in (cairo): ;;; ERROR: missing interface for module (cairo) LOAD (gnu build vm) LOAD (gnu tests) LOAD (gnu tests base) LOAD (gnu tests nfs) LOAD (gnu tests install) warning: 'waitpid' -1 failed unexpectedly: No child processes Backtrace: In ice-9/boot-9.scm: 3088: 19 [#] In unknown file: ?: 18 [primitive-load-path "gnu/tests/install" ...] In ice-9/eval.scm: 453: 17 [eval # ()] 411: 16 [eval # #] 387: 15 [eval # #] 373: 14 [run-install # #] 387: 13 [eval # #] 387: 12 [eval # #] 387: 11 [eval # #] 411: 10 [eval # #] In srfi/srfi-1.scm: 573: 9 [map # (# # # # ...)] In ice-9/eval.scm: 387: 8 [eval # #] 411: 7 [eval # #] 411: 6 [eval # #] 387: 5 [eval # #] In unknown file: ?: 4 [force #>] In ice-9/eval.scm: 411: 3 [eval # #] 411: 2 [eval # #] In ice-9/popen.scm: 98: 1 [close-process # 28701] In unknown file: ?: 0 [waitpid 28701 #] ERROR: In procedure waitpid: ERROR: In procedure waitpid: No child processes make[2]: *** [Makefile:4929: make-go] Error 1 make[2]: Leaving directory '/home/cwebber/src/guix' make[1]: *** [Makefile:4072: all-recursive] Error 1 make[1]: Leaving directory '/home/cwebber/src/guix' make: *** [Makefile:2728: all] Error 2 This is on commit 21abf092a49f0ce80cbfff5cccabb7dbf53abf96 If instead I switch back to c2662820f359be19262cdd5d564e6a0dddc43281 I can compile Guix again. I did a git-bisect to find what commit was breaking things. According to git-bisect, the perpetrator is: 63302a4e55241a41eab4c21d7af9fbd0d5817459 is the first bad commit commit 63302a4e55241a41eab4c21d7af9fbd0d5817459 Author: Ludovic Courtès Date: Mon Feb 6 23:47:09 2017 +0100 Add (gnu build shepherd). * gnu/build/shepherd.scm: New file. * gnu/local.mk (GNU_SYSTEM_MODULES): Add it. :04 04 7a07b30ebec719aca2fba4c2776f7152e669a1ee 63eb6bc3fa184fc42c3d469d594fc056f16b7892 Mgnu bisect run success I've confirmed this by double-checking that I can build the commit before but not this commit. I don't really know why this fails, but it looks like it's somehow triggering a remote process in some way related to tests and shepherd... which is confusing, because I don't think this happening during tests. - Chris
