bug#37694: Problem with guix pull from local repository
Hi, Guix tells me to report the following so I do: I have a local Guix checkout and wanted to test a local change in action. So as root I executed: > guix pull --url="/home/tibbe/src/guix" --branch=master Which resulted in: > Updating channel 'guix' from Git repository at '/home/tibbe/src/guix'... > Building from this channel: > guix /home/tibbe/src/guix 427e7a4 > Computing Guix derivation for 'x86_64-linux'... \@ build-started > /gnu/store/qyjfhsqsdy57hvh0axgr4l34v2a4d75m-guix-1.0.1-7.fc1fe72-checkout.drv > - x86_64-linux > /var/log/guix/drvs/qy//jfhsqsdy57hvh0axgr4l34v2a4d75m-guix-1.0.1-7.fc1fe72-checkout.drv.bz2 > 6671 > @ build-log 6671 41 > guile: warning: failed to install locale > @ build-log 6671 152 > environment variable `PATH' set to > `/gnu/store/i2cdl0hvrml8hjdqplqln8didnvxkgp5-gzip-1.10/bin:/gnu/store/jh17p4sns7dvbizwz58gdh953qpic144-tar-1.32/bin' > @ build-log 6671 116 > Initialized empty Git repository in > /gnu/store/sin7s2f4qw3f17fs8gfv4n059dciml9j-guix-1.0.1-7.fc1fe72-checkout/.git/ > |@ build-log 6671 102 > error: Server does not allow request for unadvertised object > fc1fe722a05318ac05a71a0b127f231631e2843f > @ build-log 6671 55 > Failed to do a shallow fetch; retrying a full fetch... > /@ build-log 6671 41 > From https://git.savannah.gnu.org/r/guix > @ build-log 6671 68 > * [new branch] core-updates-> origin/core-updates > @ build-log 6671 68 > * [new branch] guile-daemon-> origin/guile-daemon > @ build-log 6671 75 > * [new branch] imagemagick-updates -> origin/imagemagick-updates > @ build-log 6671 76 > * [new branch] install-doc-overhaul-> origin/install-doc-overhaul > @ build-log 6671 62 > * [new branch] master -> origin/master > @ build-log 6671 59 > * [new branch] nix -> origin/nix > @ build-log 6671 70 > * [new branch] python-updates -> origin/python-updates > @ build-log 6671 66 > * [new branch] qt-updates -> origin/qt-updates > @ build-log 6671 75 > * [new branch] reproduce-bug-29774 -> origin/reproduce-bug-29774 > @ build-log 6671 61 > * [new branch] rhel6 -> origin/rhel6 > @ build-log 6671 63 > * [new branch] snapper -> origin/snapper > @ build-log 6671 63 > * [new branch] staging -> origin/staging > @ build-log 6671 70 > * [new branch] version-0.10.0 -> origin/version-0.10.0 > @ build-log 6671 70 > * [new branch] version-0.11.0 -> origin/version-0.11.0 > @ build-log 6671 70 > * [new branch] version-0.12.0 -> origin/version-0.12.0 > @ build-log 6671 70 > * [new branch] version-0.13.0 -> origin/version-0.13.0 > @ build-log 6671 70 > * [new branch] version-0.14.0 -> origin/version-0.14.0 > @ build-log 6671 70 > * [new branch] version-0.15.0 -> origin/version-0.15.0 > @ build-log 6671 70 > * [new branch] version-0.16.0 -> origin/version-0.16.0 > @ build-log 6671 69 > * [new branch] version-0.8.3 -> origin/version-0.8.3 > @ build-log 6671 69 > * [new branch] version-0.9.0 -> origin/version-0.9.0 > @ build-log 6671 69 > * [new branch] version-1.0.0 -> origin/version-1.0.0 > @ build-log 6671 69 > * [new branch] version-1.0.1 -> origin/version-1.0.1 > @ build-log 6671 69 > * [new branch] wip-bootstrap -> origin/wip-bootstrap > @ build-log 6671 78 > * [new branch] wip-build-systems-gexp -> origin/wip-build-systems-gexp > @ build-log 6671 69 > * [new branch] wip-buildroot -> origin/wip-buildroot > @ build-log 6671 65 > * [new branch] wip-check -> origin/wip-check > @ build-log 6671 69 > * [new branch] wip-container -> origin/wip-container > @ build-log 6671 72 > * [new branch] wip-cross-system-> origin/wip-cross-system > @ build-log 6671 66 > * [new branch] wip-deploy -> origin/wip-deploy > @ build-log 6671 67 > * [new branch] wip-deploy2 -> origin/wip-deploy2 > @ build-log 6671 71 > * [new branch] wip-gexp-grafts -> origin/wip-gexp-grafts > @ build-log 6671 72 > * [new branch] wip-gexp-hygiene-> origin/wip-gexp-hygiene > @ build-log 6671 69 > * [new branch] wip-git-https -> origin/wip-git-https > @ build-log 6671 69 > * [new branch] wip-gnome3.30 -> origin/wip-gnome3.30 > @ build-log 6671 75 > * [new branch] wip-go-build-system -> origin/wip-go-build-system > @ build-log 6671 66 > * [new branch] wip-grafts -> origin/wip-grafts > @ build-log 6671 75 > * [new branch] wip-haskell-updates -> origin/wip-haskell-updates > @ build-log 6671 64 > * [new branch] wip-hurd-> origin/wip-hurd > @ build-log 6671 64 > * [new branch] wip-ipfs
bug#35279: emacs-xwidget does not provide support for xwidgets
Hi, I noticed that the emacs from the emacs-xwidget package does not actually provide support for xwidgets. The last commit I could verify it with is 3ee0e4071e8063f6404f8e7c43f175a80f652112 but the problem was also there with version 26.1. You can easily check whether the problem occurs by the build log: Whether xwidget support will be enabled will be printed at the end of the configure script. Emacs will happily build versions without xwidget support even if you specified '--with-xwidgets' on the command line. Maybe we can add a check to the package definition that checks whether the emacs-xwidgets build actually supports xwidgets. The section `Building Emacs with the '--with-xwidgets' option now requires WebKit2.` from the Emacs 26.2 news indicates that we probably just need to update to WebKit2 to fix the problem. Tim.
bug#32458: Acknowledgement (SDL SEGFAULTs on foreign distro)
Hi, So the machine that has this error has the following properties: Distro: Debian Stretch ``` sources.list deb http://ftp.de.debian.org/debian/ stretch main deb-src http://ftp.de.debian.org/debian/ stretch main deb http://security.debian.org/debian-security stretch/updates main deb-src http://security.debian.org/debian-security stretch/updates main # stretch-updates, previously known as 'volatile' deb http://ftp.de.debian.org/debian/ stretch-updates main deb-src http://ftp.de.debian.org/debian/ stretch-updates main ``` Bug still apears after: `apt update && apt upgrade -y` `uname -a` returns: ``` Linux 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux ``` (I substituted the real hostname with ) Loaded Xorg modules: `grep LoadModule /var/log/Xorg.0.log` ``` [11.843] (II) LoadModule: "glx" [11.856] (II) LoadModule: "ati" [11.857] (II) LoadModule: "radeon" [11.860] (II) LoadModule: "modesetting" [11.861] (II) LoadModule: "fbdev" [11.861] (II) LoadModule: "vesa" [11.870] (II) LoadModule: "fbdevhw" [11.872] (II) LoadModule: "fb" [11.873] (II) LoadModule: "dri2" [11.874] (II) LoadModule: "glamoregl" [12.394] (II) LoadModule: "ramdac" [12.705] (II) LoadModule: "libinput" ``` The bug still appears after pulling a new version of guix (e5ad2cdf1): `guix environment --ad-hoc teeworlds -- teeworlds` for example SEGFAULTs. I hope this information helps reproducing the bug. Tim. signature.asc Description: OpenPGP digital signature
bug#32458: Acknowledgement (SDL SEGFAULTs on foreign distro)
binQKG_qXIC9F.bin Description: application/pgp-encrypted bingIs13rntrH.bin Description: Binary data
bug#33359: On emacs-clang-format
On 14.11.2018 11:48, Pierre Neidhardt wrote: >> : - The license is incorrect. The version that is cloned from github >> : also seems to have some licensing issues (Missing full license...) > > Which license? > The emacs-clang-format package definition claims that the package is licensed under the GPLv3+. The files in the repository are licensed under the same license that clang is licensed under ( The headers of the files actually say that they are from the LLVM project). This means the package is licensed under University of Illinois/NCSA Open Source License. So while it would probably be legal to distribute binaries and source code under the terms of the GPL this should probably be fixed :) Tim. signature.asc Description: OpenPGP digital signature
bug#33359: On emacs-clang-format
Hi,
I noticed that someone packaged emacs-clang-format.
There are some problems with the current package definition:
- clang already distributes the same functionality (Maybe I am missing a
feature that clangs version does not have though).
- The package also includes integration for clang-rename.
- The package should probably have a more generic name and function as a
package for all emacs integration clang offers.
- The clang package is installing the same files under share/clang.
Maybe those should be removed.
- The license is incorrect. The version that is cloned from github
also seems to have some licensing issues (Missing full license...)
You'll find an example package definition attached.
This can probably be optimized a little bit more so that the full clang
tarball does not need to be extracted twice.
Tim.
From bc5d4139c28c10fc5a52466fd2b4182560fed8c6 Mon Sep 17 00:00:00 2001
From: Tim Gesthuizen
Date: Mon, 12 Nov 2018 22:27:41 +0100
Subject: [PATCH] * gnu: Add emacs-clang-tooling.
---
gnu/packages/emacs.scm | 73 +-
1 file changed, 37 insertions(+), 36 deletions(-)
diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index 3e32998a9..e1e751d4b 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -12490,42 +12490,43 @@ correctly.")
@end itemize\n")
(license license:gpl3+
-(define-public emacs-clang-format
- (let ((commit "5556c31528af2661bed3011bd63ffc0ed44e18a0"))
-(package
- (name "emacs-clang-format")
- (version (git-version "0.0.0" "1" commit))
- (source (origin
-(method git-fetch)
-(uri (git-reference
- (url "https://github.com/emacsorphanage/clang-format";)
- (commit commit)))
-(file-name (git-file-name name version))
-(sha256
- (base32
- "0ynvnp3vrcpngmwakb23xv4xn7jbkg43s196q7pg9nkl13x4n2nq"
- (build-system emacs-build-system)
- (inputs
- `(("clang" ,clang)))
- (arguments
- `(#:phases
- (modify-phases %standard-phases
- (add-after 'unpack 'configure
- (lambda* (#:key inputs #:allow-other-keys)
- (let ((clang (assoc-ref inputs "clang")))
- ;; Repo is read-only.
- (chmod "clang-format.el" #o644)
- (emacs-substitute-variables "clang-format.el"
- ("clang-format-executable"
-(string-append clang "/bin/clang-format"
- #t)
- (home-page "https://github.com/emacsorphanage/clang-format";)
- (synopsis "Format code using clang-format")
- (description "This package allows to filter code through clang-format to
-fix its formatting. @command{clang-format} is a tool that formats C/C++/Obj-C
-code according to a set of style options, see
-@url{http://clang.llvm.org/docs/ClangFormatStyleOptions.html}.";)
- (license license:gpl3+
+(define-public emacs-clang-tooling
+ (package
+(inherit clang)
+(name "emacs-clang-tooling")
+(version (package-version clang))
+(source
+ (origin
+ (method url-fetch)
+ (uri (string-append "http://llvm.org/releases/";
+ version "/cfe-" version ".src.tar.xz"))
+ (sha256 (base32 "0rxn4rh7rrnsqbdgp4gzc8ishbkryhpl1kd3mpnxzpxxhla3y93w"))
+ (snippet
+ '(begin
+ (copy-file "tools/clang-rename/clang-rename.el" "clang-rename.el")
+ (copy-file "tools/clang-format/clang-format.el" "clang-format.el")
+(build-system emacs-build-system)
+(inputs
+ `(("clang" ,clang)))
+(arguments
+ `(#:phases
+ (modify-phases %standard-phases
+ (add-after 'unpack 'configure
+ (lambda* (#:key inputs #:allow-other-keys)
+ (let ((clang (assoc-ref inputs "clang")))
+ ;; Repo is read-only.
+ (chmod "clang-format.el" #o644)
+ (emacs-substitute-variables "clang-format.el"
+ ("clang-format-executable"
+ (string-append clang "/bin/clang-format")))
+ (chmod "clang-rename.el" #o644)
+ (emacs-substitute-variables "clang-rename.el"
+ ("clang-rename-binary"
+ (string-append clang "/bin/clang-rename"
+ #t)
+(synopsis "Integration of clang-tooling into emacs")
+(description "This package provides integration of clang tooling into emacs.
+It can be used with C/C++/Obj-C code.")))
(define-public emacs-gtk-look
(package
--
2.19.1
signature.asc
Description: OpenPGP digital signature
bug#32458: Acknowledgement (SDL SEGFAULTs on foreign distro)
Hi, On 22.10.2018 22:50, Marius Bakke wrote: > One thing that might be worth a try before bisecting Mesa itself is > building against LLVM 3.9.1 again. I don't know the relevance of the > "exactly 3.9.1 for swrast" comment from that commit. Just a quick update: I tried the following things and all of them failed but in a little more helpful manor: - Building current version of mesa with LLVM 3.9.1: mesa fails to configure -> Some part needs at least LLVM version 4. - Building old mesa with LLVM 3.9.1: unit tests in the testsuite of mesa fail which causes the build to fail. I could not investigate the failure yet but it seems quite promising. > Out of curiosity, which graphics driver are you using? The radeon driver with non free firmware, sadly :( I cannot get anything free to run and I will switch to another computer as my main computer soon. I hope I can find the cause for the bug before I switch. Tim. signature.asc Description: OpenPGP digital signature
bug#32458: Acknowledgement (SDL SEGFAULTs on foreign distro)
Hi, I did another bisect to find the second cause of failure. I used the input rewriting technique but with the fixed libepoxy definition: >> (use-modules (gnu packages) >> (gnu packages games) >> (gnu packages gl) >> (guix packages) >> (guix profiles)) >> >> (define libepoxy-legacy >> (package >> (inherit libepoxy) >> (version "1.4.0"))) > > This package is missing a (source ...) field. So this only pretends to > be 1.4.0, but is actually the same as the inherited one. > > (Also, should it not be 1.5.0?) Yes it should be. Something made me think the expression evaluating to the origin object in the original libepoxy definition would be reevaluated. And it also should be 1.5.0. I started using the small guile script using guile-sdl2 again, simply because I do not need to close the window manually if a commit is good and the program starts. Otherwise the bisect would still need human input. You can find the scripts that I used attached as a tar archive. It has some hardcoded paths though. Execute the check.sh script to check the current commit. After a really long bisect and tons of package rebuilding git found commit faccae1c3769c90694c2b7eee0e4e9ab53049a8f to be guilty. The commit updates mesa so it seems quite possible. I don't have that much time right now but I will try to revert the two commits found so far and see whether this gets OpenGL running again on the master branch. Tim. debug-scripts.tar.gz Description: application/gzip
bug#32458: Acknowledgement (SDL SEGFAULTs on foreign distro)
Hi, I tried to bisect again using the input rewriting method. You find the two scripts for this attached. It turned out that this does not only take a lot of time for building single versions of guix and the modified teeworlds package, but it also brings up the bug with the missing pkg-config package in the package definition of teeworlds. Because of this I stopped trying to bisect with the input rewritten versions of the packages and tried reverting as you suggested. Reverting on top of 0d6f84aab, guix and packages using OpenGL build, but still segfaults on initialization. I hope you have another good idea, as bisecting with the above method would probably take a lot of time. Tim. check.sh Description: application/shellscript (use-modules (gnu packages) (gnu packages games) (gnu packages gl) (guix packages) (guix profiles)) (define libepoxy-legacy (package (inherit libepoxy) (version "1.4.0"))) (define with-libepoxy-legacy (package-input-rewriting (list (cons libepoxy libepoxy-legacy (define teeworlds-fixed (with-libepoxy-legacy teeworlds)) (packages->manifest (list teeworlds-fixed)) signature.asc Description: OpenPGP digital signature
bug#32458: Acknowledgement (SDL SEGFAULTs on foreign distro)
On 08.10.2018 20:28, Marius Bakke wrote: > If reverting did not help, I doubt rebasing it away will do a > difference. It also sounds very tedious! I stopped rebasing. It was too tedious. > Have you been able to find a commit that definitely works? Say, > 0dd91619a597b52bcb5d6d1bb675a9eb65242c44 (0.14)? Now that you have a I could verify that this commit also works. > 0dd91619a597b52bcb5d6d1bb675a9eb65242c44 (0.14)? Now that you have a > good test case, it should be easier to script the bisect (just make sure > to invoke "make clean && make" between runs to avoid ABI issues). But I have bisected already :) On 22.08.2018, Tim Gesthuizen wrote: > This bisect passed without a single skip. It reports that the bug was > first introduced by 5318b103ff277efbac248a066d162589a9083baa (which is > the first commit after a larger merge). Maybe you missed that mail. The problem is that reverting the commit does not solve the bug on the current master branch. So I am searching for a good way of finding another bug through bisecting. This would mean that I would need to apply a patch of some form to make sure that the libepoxy problem is fixed before running the bisect script again. This is why I tried to rebase the master branch to not include commits updating libepoxy. I hope my problem is more clear now. Maybe there is another way that is just too obvious and simple. If you don't have a good idea on how to do it, I will do the bisect again and do an input rewriting for the package I am building to use the old libepoxy and not the one of that revision. This will probably involve tons of package rebuilding so I am open for other approaches. Tim. signature.asc Description: OpenPGP digital signature
bug#32458: Acknowledgement (SDL SEGFAULTs on foreign distro)
On 07.10.2018 22:06, Marius Bakke wrote: > Hello! Sorry for dropping the ball on this. No problem. Nobody pressures you to help others :) > Nice catch! Earlier in the bisect, you found > 5318b103ff277efbac248a066d162589a9083baa (gnu: libepoxy: Update to > 1.5.1.). Can you try this patch and see if it makes a difference? I also noticed this and reverted the commit introducing the bug. After reverting the commit I still got a broken OpenGL in `master`. Right now I am trying to rebase the current master branch to not include the two commits updating libepoxy in order to bisect that branch again to find the thing that keeps simple reverting from working. This really takes some time as it brings every merge-conflict ever since back to life and I have to resolve them. I hope that I will not introduce new bugs during rebasing and find the time to get the rebase and the bisect going and report the other cause of failure. Tim. signature.asc Description: OpenPGP digital signature
bug#32458: Acknowledgement (SDL SEGFAULTs on foreign distro)
Hi, I tried to find some free time to investigate a little bit further in what exactly triggers the crash to happen. A few days ago I had the idea of getting a GL context through GLUT and don't use SDL at all. So I quickly investigated whether this would also crash. So I fetched the cube example (cube.c) from the OpenGL example archive: https://www.opengl.org/archives/resources/code/samples/glut_examples/examples/examples.html and compiled it through guix. You can find the exact procedure by inspecting the log attached. If I did not make an error this should proof that the problem lies in OpenGL and not in SDL. Tim. tibbe@tibbe-pc:~/src/glut-example$ guix environment --ad-hoc freeglut tibbe@tibbe-pc:~/src/glut-example$ echo $GUIX_ENVIRONMENT /gnu/store/gsfq0h6hpjz9ddvgn4g3gkl5r6gg3ink-profile tibbe@tibbe-pc:~/src/glut-example$ ls $GUIX_ENVIRONMENT etc include lib manifest share tibbe@tibbe-pc:~/src/glut-example$ gcc cube.c -L $GUIX_ENVIRONMENT/lib -l glut -l GL -I $GUIX_ENVIRONMENT/include /tmp/ccXMXGNS.o: In function `init': cube.c:(.text+0x321): undefined reference to `gluPerspective' cube.c:(.text+0x372): undefined reference to `gluLookAt' collect2: error: ld returned 1 exit status tibbe@tibbe-pc:~/src/glut-example$ gcc cube.c -L $GUIX_ENVIRONMENT/lib -l glut -l glu -l GL -I $GUIX_ENVIRONMENT/include ld: cannot find -lglu collect2: error: ld returned 1 exit status tibbe@tibbe-pc:~/src/glut-example$ gcc cube.c -L $GUIX_ENVIRONMENT/lib -l glut -l GLU -l GL -I $GUIX_ENVIRONMENT/include tibbe@tibbe-pc:~/src/glut-example$ ls a.out cube.c tibbe@tibbe-pc:~/src/glut-example$ ./a.out Segmentation fault signature.asc Description: OpenPGP digital signature
bug#32773: clang: missing default include paths for C++
On 22.09.2018 02:58, Robin Templeton wrote: > Hi Tim, > > Tim Gesthuizen writes: > >> As you can see from the output, clang is missing some include paths that >> gcc has. Specifying a custom `CPLUS_INCLUDE_PATH' fixes the problem: >> >> ┌ >> │ >> CPLUS_INCLUDE_PATH=$HOME/.guix-profile/include/c++:$HOME/.guix-profile/include/c++/x86_64-unknown-linux-gnu/ >> clang++ test.cc >> │ ./a.out >> └ >> >> ┌ >> │ Hello, World >> └ >> >> This is already done in the package definition for the >> `C_INCLUDE_PATH'. It is not done for C++ because clang does not >> implement a feature or build system variable for changing it. >> >> Fixing this problem would probably include an upstream patch enabling a >> similar feature for C++ for what is already done in C and configuring >> this variable in build phase to add the same include paths that g++ has. > > Another solution, maybe simpler than a new environment variable, is to > have clang use the C++ include path from its gcc input. On FHS systems, > clang can find C++ headers using the GCC_INSTALL_PREFIX configure > option, but it doesn't work under Guix because the GCC package puts > headers and libraries in separate outputs. Guix already patches clang to > hardcode some library directories; maybe something similar could be done > for C++ headers. (I think the function to modify for this would be > Linux::addLibStdCxxIncludePaths in lib/Driver/ToolChains/Linux.cpp.) > Hi Robin, I also found that section and the environment variable while debugging clang. I did not know about that variable even though its documented and Guix uses it. I've created a debug build of clang for investigating and pointing GCC_INSTALL_PREFIX to the GCC input and not the lib part fixes the problem for me. I don't know from where this build pulls crt1.o. I will try changing GCC_INSTALL_PREFIX in the guix package definition and see whether that fixes the bug. Tim.
bug#32773: clang: missing default include paths for C++
On 19.09.2018 20:33, Pjotr Prins wrote: > Hi Tim, > > I am not sure this helps but in a project I have I use > > CPPFLAGS= -std=c++11 > > and > > CPPFLAGS += -I$(GUIX)/include/c++ > -I$(GUIX)/include/c++/x86_64-unknown-linux-gnu > > to find include files in Guix context with clang. Where $(GUIX) is the > profile. > > Similar to yours. Glad to hear of a better way. Yes, that seems to be quite the same to my workaround. Its just that this is a workaround that is difficult to get working in some contexts: I want to use emacs-irony-mode through guix which is not really useable because it won't autocomplete any std::* stuff. If you take all packages that might want to use libclang and other features of clang it might be a better solution to find a proper fix for this problem. Also both workarounds need a user profile that is cluttered with all include files. I had a quick look into clangs source code how C_INCLUDE_DIRS is implemented. It should be more or less easy to add the same option for C++ (even C_INCLUDE_DIRS seems to be tinkered in to me). I just wanted to file a bug about this because fixing this is not trivial and I am not sure whether I will find the time right away to fix it. Fixing it would also have the benefit that I could send the patch to the LLVM mailing list and we might see the change upstream in the next LLVM version. Tim.
bug#32773: clang: missing default include paths for C++
Hi,
I noticed the following bug in clang when installed through guix:
Compiling C++ programs does not work because the include path is not set
correctly.
I will use the following test program for compling:
┌
│ #include
│
│ int
│ main()
│ {
│ std::cout << "Hello, World\n";
│ }
└
When I now compile using clang I get the following error message:
┌
│ which clang++
│ clang++ test.cc 2>&1
│ exit 0
└
┌
│ /home/tibbe/.guix-profile/bin/clang++
│ test.cc:1:10: fatal error: 'iostream' file not found
│ #include
│^~
│ 1 error generated.
└
┌
│ which g++
│ g++ test.cc 2>&1
│ exit 0
└
┌
│ /home/tibbe/.guix-profile/bin/g++
└
As you can see g++ has no problem compiling the code, but clang++ cannot
find the `' header. This is due to the already mentioned bad
include paths:
┌
│ g++ -v test.cc 2>&1
│ clang++ -v test.cc 2>&1
│ exit 0
└
┌
│ Using built-in specs.
│ COLLECT_GCC=g++
│
COLLECT_LTO_WRAPPER=/gnu/store/758qfjvn4wnsrhrr08pmwfr77vmcq4q2-gcc-8.2.0/libexec/gcc/x86_64-unknown-linux-gnu/8.2.0/lto-wrapper
│ Target: x86_64-unknown-linux-gnu
│ Configured with:
│ Thread model: posix
│ gcc version 8.2.0 (GCC)
│ COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
│
/gnu/store/758qfjvn4wnsrhrr08pmwfr77vmcq4q2-gcc-8.2.0/libexec/gcc/x86_64-unknown-linux-gnu/8.2.0/cc1plus
-quiet -v -D_GNU_SOURCE test.cc -quiet -dumpbase test.cc -mtune=generic
-march=x86-64 -auxbase test -version -o /tmp/cceSqDtK.s
│ GNU C++14 (GCC) version 8.2.0 (x86_64-unknown-linux-gnu)
│ compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version
4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP
│
│ GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
│ ignoring nonexistent directory "/no-gcc-local-prefix/include"
│ ignoring nonexistent directory
"/gnu/store/bmaxmigwnlbdpls20px2ipq1fll36ncd-gcc-8.2.0-lib/lib/gcc/x86_64-unknown-linux-gnu/8.2.0/../../../../../../../x86_64-unknown-linux-gnu/include"
│ #include "..." search starts here:
│ #include <...> search starts here:
│ /home/tibbe/.guix-profile/include
│ /gnu/store/758qfjvn4wnsrhrr08pmwfr77vmcq4q2-gcc-8.2.0/include/c++
│
/gnu/store/758qfjvn4wnsrhrr08pmwfr77vmcq4q2-gcc-8.2.0/include/c++/x86_64-unknown-linux-gnu
│
/gnu/store/758qfjvn4wnsrhrr08pmwfr77vmcq4q2-gcc-8.2.0/include/c++/backward
│
/gnu/store/bmaxmigwnlbdpls20px2ipq1fll36ncd-gcc-8.2.0-lib/lib/gcc/x86_64-unknown-linux-gnu/8.2.0/include
│
/gnu/store/bmaxmigwnlbdpls20px2ipq1fll36ncd-gcc-8.2.0-lib/lib/gcc/x86_64-unknown-linux-gnu/8.2.0/include-fixed
│ /gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/include
│ End of search list.
│ GNU C++14 (GCC) version 8.2.0 (x86_64-unknown-linux-gnu)
│ compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version
4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP
│
│ GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
│ Compiler executable checksum: 238b7d99644945f4ccaa2a89b02dcd25
│ COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
│ as -v --64 -o /tmp/ccZKb9XQ.o /tmp/cceSqDtK.s
│ GNU assembler version 2.30 (x86_64-unknown-linux-gnu) using BFD
version (GNU Binutils) 2.30
│
COMPILER_PATH=/gnu/store/758qfjvn4wnsrhrr08pmwfr77vmcq4q2-gcc-8.2.0/libexec/gcc/x86_64-unknown-linux-gnu/8.2.0/:/gnu/store/758qfjvn4wnsrhrr08pmwfr77vmcq4q2-gcc-8.2.0/libexec/gcc/x86_64-unknown-linux-gnu/8.2.0/:/gnu/store/758qfjvn4wnsrhrr08pmwfr77vmcq4q2-gcc-8.2.0/libexec/gcc/x86_64-unknown-linux-gnu/:/gnu/store/bmaxmigwnlbdpls20px2ipq1fll36ncd-gcc-8.2.0-lib/lib/gcc/x86_64-unknown-linux-gnu/8.2.0/:/gnu/store/bmaxmigwnlbdpls20px2ipq1fll36ncd-gcc-8.2.0-lib/lib/gcc/x86_64-unknown-linux-gnu/
│
LIBRARY_PATH=/home/tibbe/.guix-profile/lib/:/home/tibbe/.guix-profile/lib/:/gnu/store/bmaxmigwnlbdpls20px2ipq1fll36ncd-gcc-8.2.0-lib/lib/gcc/x86_64-unknown-linux-gnu/8.2.0/:/gnu/store/bmaxmigwnlbdpls20px2ipq1fll36ncd-gcc-8.2.0-lib/lib/gcc/x86_64-unknown-linux-gnu/8.2.0/../../../:/gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/lib
│ COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
│
/gnu/store/758qfjvn4wnsrhrr08pmwfr77vmcq4q2-gcc-8.2.0/libexec/gcc/x86_64-unknown-linux-gnu/8.2.0/collect2
-plugin
/gnu/store/758qfjvn4wnsrhrr08pmwfr77vmcq4q2-gcc-8.2.0/libexec/gcc/x86_64-unknown-linux-gnu/8.2.0/liblto_plugin.so
-plugin-opt=/gnu/store/758qfjvn4wnsrhrr08pmwfr77vmcq4q2-gcc-8.2.0/libexec/gcc/x86_64-unknown-linux-gnu/8.2.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccKNZuuX.res
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc
--eh-frame-hdr -m elf_x86_64 -dynamic-linker
/gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/lib/ld-linux-x86-64.so.2
/home/tibbe/.guix-profile/lib/crt1.o
/home/tibbe/.guix-profile/lib/crti.o
/gnu/store/bmaxmigwnlbdpls20px2ipq1fll36ncd-gcc-8.2.0-lib/lib/gcc/x86_64-unknown-l
bug#32458: Acknowledgement (SDL SEGFAULTs on foreign distro)
On 20.08.2018 22:59, Marius Bakke wrote: > Hello again, > > Just a quick feedback on the bisect script: > > Tim Gesthuizen writes: > >> #!/bin/sh >> >> cd $HOME/src/guix/build >> (cd ..; ./bootstrap) || exit 125 >> (../configure --localstatedir=/var && make -j8) || exit 125 >> PATH=$(./pre-inst-env guix build teeworlds | grep /gnu/store | tail -n 1) >> || exit 125 >> $PATH/bin/teeworlds || exit 1 > > I suggest not running "./bootstrap" and "./configure" in between runs. > "make" will invoke ./configure (with current parameters) if necessary. > > Then it can be reduced to a two-liner: > > > > > Again, nice work; I look forward to fix this bug :-) > I have changed the bisect script. You find the new one attached. I have never worked with autoconf so I just wanted to be sure that everything would configure correctly and not cause problems. > I think the reason > you had to skip these commits were because of ABI issues in the git > checkout (incompatible Guile objects). Well, I also somewhat forgot that I fixed teeworlds not a long time ago (see commit e402a66b07c12aadf5eed1472110684831f1f498)... so any compilations of teeworlds before were doomed to fail. This is not as bad as it sounds because remembering this gave me a commit that I could definitely verify as good. With this new starting point I started bisecting again from that commit marked as the first good one to the current commit on master marked as the first bad one. This bisect passed without a single skip. It reports that the bug was first introduced by 5318b103ff277efbac248a066d162589a9083baa (which is the first commit after a larger merge). I also noticed something odd: After I realized that using teeworlds for verifying SDL could not have been a very wise decision I wrote a little guile script using guile-sdl2 (sdl.scm). I tried to bisect using this script for SDL verification and found out that I could not find any commits where SDL2 worked for me. Even in commits where teeworlds builds and runs without a problem SDL2 will always crash. Also there are some revisions where teeworlds starts with bad resolution (the window begins on my second monitor and ends somewhere on my first monitor). But that is probably not of interest now. I hope these informations help. If I forgot something in the rush of writing this mail feel free to ask for it. test.sh Description: application/shellscript (use-modules (sdl2) (sdl2 render) (sdl2 surface) (sdl2 video)) (define (draw ren) (clear-renderer ren) (present-renderer ren) (sleep 2)) (sdl-init) (call-with-window (make-window) (lambda (window) (call-with-renderer (make-renderer window) draw))) (sdl-quit) signature.asc Description: OpenPGP digital signature
bug#32458: Acknowledgement (SDL SEGFAULTs on foreign distro)
I tried to bisect the bug by building Guix from git. You find the script I used as well as some information about the bisect attached (full log is 17MB so I copied the most important things). test.sh Description: application/shellscript There are only 'skip'ped commits left to test. The first bad commit could be any of: 68adf4a840b200a585f5428cc3657cba117ba9a6 e0c9aed8206c455dde393d1a1c3e2ac4b3615c30 6069bb0ab4ce5ff25d235288bc005b7ec55b75a1 a3be2ac9f95c632a6d5f20790b8b2f6450d6f6e7 543689f3fdae7ec746817b44cae777408733b16f fa497c73acb1b8307ebb81ef8acd4de1a2e4fde9 7e0f04635b942e572ee2fed8ddb756b047117265 87dc306bfe48469d33b4d0fa9d2ee7e66e56acbf 1fbad3ad224a92c8e2562b4f16ec20d8e9615fac db481977615de3ebf7faff16edb938d3461ca486 0ed990530f08ceb1545a44b523661888f82a29a0 a06e52279a223ff2d132e5ecefc0ebe73f51d4d7 0b5c2fc338ba0e37679afb9964700219b06498d8 aac2006d8276ac7ed3876b879f1816e57379aa25 7d475dd4ece966faae71323f309b65314b27a5a3 91d84ac898f7e09cc17f869ef6d56232db013625 06dbfb5d197db7502ed65c1019e96f3f02c34b7a 9a1f92a6e02c28767cc77437ba29fb82271652c4 02fcc6f240946cfd51bfe548e260b2f3150f0ab4 77c74789d4ce7b8201f947cb688b80efe7a774ec bd1efded37107cfffe69cc7e9730acf8ba2957a7 eb6a5dab5cf0f85fbc4eda4b6f7956eed464c3cf 4bbd92076af9fedc99b9369151e067db653869d0 bba29e106b55152f70f7cec745e24bc077e9a797 cf0d6d836730f7bdc714ecfa4287f72e029b9970 e688bfc033160e0f614bf99f3c74dcb34b427d20 d54303215e93bb3c89a94daaa56324c703d717a1 ffc43471afa6da50e02a12433ea9626aea586f35 5318b103ff277efbac248a066d162589a9083baa b5724230fed2d043206df20d12a45bb962b7ee77 a032b4454b3fc67e11e9fc2d8c2345288065fa29 We cannot bisect more! bisect run cannot continue any more Bisect Rest (31) a032b4454 * bad Merge branch 'master' into staging b5724230f * skip-b5724230fed2d043206df20d12a45bb962b7ee77 gnu: bluez: Update to 5.50. ffc43471a * skip-ffc43471afa6da50e02a12433ea9626aea586f35 gnu: meson: Update to 0.46.1. e688bfc03 * skip-e688bfc033160e0f614bf99f3c74dcb34b427d20 gnu: libepoxy: Update to 1.5.2. 4bbd92076 * skip-4bbd92076af9fedc99b9369151e067db653869d0 gnu: libdmx: Update to 1.1.4. bd1efded3 * skip-bd1efded37107cfffe69cc7e9730acf8ba2957a7 gnu: xkbcomp: Update to 1.4.2. 77c74789d * skip-77c74789d4ce7b8201f947cb688b80efe7a774ec gnu: xf86-video-mach64: Update to 6.9.6. 9a1f92a6e * skip-9a1f92a6e02c28767cc77437ba29fb82271652c4 gnu: mesa: Update to 18.0.5. 91d84ac89 * skip-91d84ac898f7e09cc17f869ef6d56232db013625 gnu: libinput: Update to 1.11.0. 0b5c2fc33 * skip-0b5c2fc338ba0e37679afb9964700219b06498d8 gnu: doxygen: Update to 1.8.14. a06e52279 * skip-a06e52279a223ff2d132e5ecefc0ebe73f51d4d7 gnu: mesa: Restore wayland platform. 1fbad3ad2 * skip-1fbad3ad224a92c8e2562b4f16ec20d8e9615fac gnu: postgresql: Use INVOKE. 7e0f04635 * skip-7e0f04635b942e572ee2fed8ddb756b047117265 gnu: postgresql: Update to 10.4 [fixes CVE-2018-1115]. fa497c73a * skip-fa497c73acb1b8307ebb81ef8acd4de1a2e4fde9 gnu: libdrm: Update to 2.4.92. a3be2ac9f * skip-a3be2ac9f95c632a6d5f20790b8b2f6450d6f6e7 gnu: xorg-server: Update to 1.20.0. 68adf4a84 * skip-68adf4a840b200a585f5428cc3657cba117ba9a6 gnu: wayland-protocols: Update to 1.14. e0c9aed82 * skip-e0c9aed8206c455dde393d1a1c3e2ac4b3615c30 gnu: mesa: Update to 18.0.4. 6069bb0ab * skip-6069bb0ab4ce5ff25d235288bc005b7ec55b75a1 gnu: tzdata: Update to 2018e. 543689f3f * skip-543689f3fdae7ec746817b44cae777408733b16f gnu: python-mako: Update to 1.0.7. 87dc306bf * skip-87dc306bfe48469d33b4d0fa9d2ee7e66e56acbf gnu: libaio: Update to 0.3.111. db4819776 * skip-db481977615de3ebf7faff16edb938d3461ca486 gnu: mesa: Update to 18.0.2. 0ed990530 * skip-0ed990530f08ceb1545a44b523661888f82a29a0 gnu: zathura-pdf-poppler: Update to 0.2.9. aac2006d8 * skip-aac2006d8276ac7ed3876b879f1816e57379aa25 gnu: zathura-pdf-mupdf: Update to 0.3.3. 7d475dd4e * skip-7d475dd4ece966faae71323f309b65314b27a5a3 gnu: zathura-djvu: Update to 0.2.8. 06dbfb5d1 * skip-06dbfb5d197db7502ed65c1019e96f3f02c34b7a gnu: zathura-ps: Update to 0.2.6. 02fcc6f24 * skip-02fcc6f240946cfd51bfe548e260b2f3150f0ab4 gnu: zathura-cb: Update to 0.1.8. eb6a5dab5 * skip-eb6a5dab5cf0f85fbc4eda4b6f7956eed464c3cf gnu: zathura: Update to 0.3.9. bba29e106 * skip-bba29e106b55152f70f7cec745e24bc077e9a797 gnu: girara: Update to 0.2.9. cf0d6d836 * skip-cf0d6d836730f7bdc714ecfa4287f72e029b9970 gnu: meson: Update to 0.46.0. d54303215 * skip-d54303215e93bb3c89a94daaa56324c703d717a1 @ gnu: gtk+: Update to 3.22.30. 5318b103f * skip-5318b103ff277efbac248a066d162589a9083baa gnu: libepoxy: Update to 1.5.1. Bisect Log (44) git bisect start 'master' '5ae27f577' 8d4805ba2 bad services: cuirass: Put data in /var/lib to avoid removal at boot. 5ae27f577 good gnu: gcc-toolchain: Add version 8. git bisect bad 9f2adb2f19db6d2e2234df15b0e24c5d01b9181c 9f2adb2f1 bad gnu: emacs-pulseaudio-control: Update to 20180627. git bisect good 9866825961cbffa6a05f685d9cc71388d21a0a68 986682596 good gnu: emacs-biblio: Add missing dependencies. git bisect bad f7e248396ba698b7de99414039d9db02050bc7d3 f7e248396 ba
bug#32458: SDL SEGFAULTs on foreign distro
Hi,
since a few days now SDL2 and SDL-1.2 are broken for me through Guix.
Running any kind of application that uses SDLs rendering mechanisms
crashes immediately while initializing window and renderer.
I tried tracking down the bug using GDB and found out that the bug
occurs while compiling/loading the shader code in my local graphics driver.
An invocation of memcpy causes a SEGFAULT during this operation.
I am running Guix on top of Debian Stretch with the radeon graphics driver.
I suspect binary incompatibility between Guix and Debians compiler to be
the cause of this problem but I cannot verify anything.
You find a log of my gdb session which includes some stacktraces from
where the program crashed.
If you need more information about my setup or technical details feel
free to ask.
I also want to note that SDL-1.2 definitely worked for me a few weeks
ago through Guix.
Sincerely,
Tim Gesthuizen
~/src/guix-tg$ gdb teeworlds
GNU gdb (GDB) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from teeworlds...(no debugging symbols found)...done.
(gdb) run
Starting program: /gnu/store/d2j6sb9c9ydcy0yqji53glh5mrxh9rfh-profile/bin/teeworlds
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/lib/libthread_db.so.1".
warning: File "/gnu/store/vla5j7pbkpcp39lsdfsmz7m9azn48lr4-gcc-5.5.0-lib/lib/libstdc++.so.6.0.21-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /gnu/store/vla5j7pbkpcp39lsdfsmz7m9azn48lr4-gcc-5.5.0-lib/lib/libstdc++.so.6.0.21-gdb.py
line to your configuration file "/home/tibbe/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/tibbe/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
[5b75af71][engine]: running on unix-linux-amd64
[5b75af71][engine]: arch is little endian
[New Thread 0x70ab6700 (LWP 13457)]
[5b75af71][storage]: couldn't open storage.cfg
[5b75af71][storage]: using standard paths
[5b75af71][storage]: added path '$USERDIR' ('/home/tibbe/.teeworlds')
[5b75af71][storage]: added path '$DATADIR' ('/gnu/store/dz8yvn7pnlgr2cqx2jik98jxpv9yyqg1-teeworlds-0.6.4/share/teeworlds/data')
[5b75af71][storage]: added path '$CURRENTDIR' ('/home/tibbe/src/guix-tg')
[5b75af71][binds]: bound f1 (282) = toggle_local_console
[5b75af71][binds]: bound f2 (283) = toggle_remote_console
[5b75af71][binds]: bound tab (9) = +scoreboard
[5b75af71][binds]: bound u (117) = +show_chat
[5b75af71][binds]: bound f10 (291) = screenshot
[5b75af71][binds]: bound a (97) = +left
[5b75af71][binds]: bound d (100) = +right
[5b75af71][binds]: bound space (32) = +jump
[5b75af71][binds]: bound mouse1 (323) = +fire
[5b75af71][binds]: bound mouse2 (324) = +hook
[5b75af71][binds]: bound lshift (304) = +emote
[5b75af71][binds]: bound rshift (303) = +spectate
[5b75af71][binds]: bound right (275) = spectate_next
[5b75af71][binds]: bound left (276) = spectate_previous
[5b75af71][binds]: bound 1 (49) = +weapon1
[5b75af71][binds]: bound 2 (50) = +weapon2
[5b75af71][binds]: bound 3 (51) = +weapon3
[5b75af71][binds]: bound 4 (52) = +weapon4
[5b75af71][binds]: bound 5 (53) = +weapon5
[5b75af71][binds]: bound mousewheelup (331) = +prevweapon
[5b75af71][binds]: bound mousewheeldown (332) = +nextweapon
[5b75af71][binds]: bound t (116) = chat all
[5b75af71][binds]: bound y (121) = chat team
[5b75af71][binds]: bound f3 (284) = vote yes
[5b75af71][binds]: bound f4 (285) = vote no
[5b75af71][console]: executing 'settings.cfg'
[5b75af71][binds]: bound tab (9) = +scoreboard
[5b75af71][binds]: bound space (32) = +jump
[5b75af71][binds]: bound 1 (49) = +weapon1
[5b75af71][binds]: bound 2 (50) = +weapon2
[5b75af71][binds]: bound 3 (51) = +weapon3
[5b75af71][binds]: bound 4 (52) = +weapon4
[5b75af71][binds]: bound 5 (53) = +weapon5
[5b75af71][bin
