bug#32773: clang: missing default include paths for C++

[fis trivial]

Tim Gesthuizen writes:

> 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.

Just put everything into `C_INCLUDE_DIRS' should make it work, see:

https://github.com/trivialfis/guixpkgs/blob/c8a6871d2757557581640d7a14b4c9167459cb14/llvm.scm#L100

Using clang/clang++ from above link to compile a single translation unit should
work.  And there is `cquery' in `code.scm' within that repository, which relies
on clang to work, you can try it out.

It shouldn't take long to make LLVM and Clang in there ready to be merge in
core-update or staging (I don't know yet), it's just I don't feel comfortable
with the `clang-from-llvm' in guix, maybe someone could help carrying it out.

Jiaming

bug#32439: guix pull as root generates too many errors.

[fis trivial]

Ludovic Courtès writes:

> Hello,
>
> fis trivial  skribis:
>
>> Leo Famulari writes:
>>
>>> On Tue, Aug 14, 2018 at 07:41:14PM +, fis trivial wrote:
>>>> Running guix pull -l as root user generates many warnings and errors. I
>>>> attached the first 1000 lines of stderr logging in this mail.
>>>>
>>>
>>>> ;;; WARNING: loading compiled file 
>>>> /root/.config/guix/current-17-link/lib/guile/2.2/site-ccache/guix/ui.go 
>>>> failed:
>>>> ;;; ERROR: In procedure make_objcode_from_file: bad header on object file: 
>>>> "\x7fELF\x02\x01\x01??\x00\x00\x00\x00\x00\x00\x00\x00"
>>>
>>> I'm not an expert on Guile or the new `guix pull`. However, I think that
>>> `guix pull` takes its Guile from the environment, because `guix pull -l`
>>> doesn't work for me when there is no Guile in PATH.
>>>
>>> Those errors look like a mismatch between Guile versions 2.0 and 2.2.
>>> Which Guile do you have available in the environment where you see that
>>> error?
>>
>> As root user, it's guile@2.0.14. Indeed, installing guile@2.2.4 from Guix 
>> fixes
>> the problem. Thanks for your insight. :)
>
> What command did you run to get the errors about?  Could you also show:
>
>   which guix
>   echo $GUILE_LOAD_PATH
>   echo $GUILE_LOAD_COMPILED_PATH
>
> ?
>

I tried the following commands after switching back the package profile to
previous state.

$ which guix
/root/.config/guix/current/bin/guix

$ echo $GUILE_LOAD_PATH
/root/.guix-profile/share/guile/site/2.2

$ echo $GUILE_LOAD_COMPILED_PATH
/root/.guix-profile/lib/guile/2.2/site-ccache:/root/.guix-profile/share/guile/site/2.2

But I can't reproduce the bug now since I cleaned up all profiles in pull.

> The new ‘guix pull’ provides a “self-contained Guix” in the sense that
> it brings all its dependencies, including Guile.  If you look at the top
> of the ‘guix’ file, you’ll see that it specifies exactly the Guile
> version that it needs:
>
> --8<---cut here---start->8---
> $ head -1 ~/.config/guix/current/bin/guix
> #!/gnu/store/p9wm67w3rfw3hlb9iljgvsfn84mz4w9d-guile-2.2.4/bin/guile 
> --no-auto-compile
> --8<---cut here---end--->8---
>
> Thus, Guile version mismatches like you experienced should normally not
> happen.
>
> Thanks for your report,
> Ludo’.

Thanks.

-- 
Jiaming

bug#32439: guix pull as root generates too many errors.

[fis trivial]

Leo Famulari writes:

> On Tue, Aug 14, 2018 at 07:41:14PM +0000, fis trivial wrote:
>> Running guix pull -l as root user generates many warnings and errors. I
>> attached the first 1000 lines of stderr logging in this mail.
>>
>
>> ;;; WARNING: loading compiled file 
>> /root/.config/guix/current-17-link/lib/guile/2.2/site-ccache/guix/ui.go 
>> failed:
>> ;;; ERROR: In procedure make_objcode_from_file: bad header on object file: 
>> "\x7fELF\x02\x01\x01??\x00\x00\x00\x00\x00\x00\x00\x00"
>
> I'm not an expert on Guile or the new `guix pull`. However, I think that
> `guix pull` takes its Guile from the environment, because `guix pull -l`
> doesn't work for me when there is no Guile in PATH.
>
> Those errors look like a mismatch between Guile versions 2.0 and 2.2.
> Which Guile do you have available in the environment where you see that
> error?

As root user, it's guile@2.0.14. Indeed, installing guile@2.2.4 from Guix fixes
the problem. Thanks for your insight. :)

I thought Guix is self-contained, so are you implying that Guix itself is not
reproducible?  Is it reasonable to request making Guix self-contained?

Thanks.

--
Jiaming

bug#31983: guix lint command error.

[Fis Trivial]

$ guix lint guix


;;; Failed to autoload make-session in (gnutls):
;;; missing interface for module (gnutls)
Backtrace:
   5 (primitive-load "/home/fis/.config/guix/current/bin/guix")
In guix/ui.scm:
  1557:12  4 (run-guix-command _ . _)
In srfi/srfi-1.scm:
640:9  3 (for-each # …)
In guix/scripts/lint.scm:
   1079:4  2 (run-checkers # …)
In srfi/srfi-1.scm:
640:9  1 (for-each # …)
In guix/scripts/lint.scm:
   490:16  0 (validate-uri #< scheme: https userinfo: #f host:…> …)

guix/scripts/lint.scm:490:16: In procedure validate-uri:
error: make-session: unbound variable


version:
guix (GNU Guix) 65f46862fa677c7b6203c8513ffdfc077624baf2
Copyright (C) 2018 the Guix authors
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

bug#31740: guix pull failed with syntax error.

[Fis Trivial]

$guix --version

guix (GNU Guix) 909301591d21d3879276e4ede3cebdcc867184f2
Copyright (C) 2018 the Guix authors
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


Actually this is the second time I bumped into this bug. It seems
non-deterministic, try it a few times might make it right. Here is the
the error message with downloading and substituting stripped out:

Updating from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
Building from Git commit 116ca65b583ba4e404289f1481dc3a3ffef1c3dd...
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
The following derivations will be built:
   /gnu/store/r195brsmnb3jgqicj7ma681yaschgyaj-compute-guix-derivation.drv
   /gnu/store/facfypp0m3g948fxzs9xg07fa45kckvk-module-import.drv
   /gnu/store/ghsnz9qn4ycg906a14glcxmxmmmh44vx-module-import-compiled.drv
;;; Failed to autoload make-session in (gnutls):
;;; missing interface for module (gnutls)
;;; Failed to autoload connection-end/client in (gnutls):
;;; missing interface for module (gnutls)
;;; ./gnu/packages.scm:92:33: warning: non-literal format string
;;; ./gnu/packages.scm:108:16: warning: non-literal format string
;;; Failed to autoload make-session in (gnutls):
;;; missing interface for module (gnutls)
;;; Failed to autoload connection-end/client in (gnutls):
;;; missing interface for module (gnutls)
;;; Failed to autoload make-session in (gnutls):
;;; missing interface for module (gnutls)
;;; Failed to autoload make-session in (gnutls):
;;; missing interface for module (gnutls)
;;; Failed to autoload connection-end/client in (gnutls):
;;; missing interface for module (gnutls)
;;; ./guix/build/download.scm:176:4: warning: possibly unbound variable 
`set-certificate-credentials-x509-trust-data!'
;;; ./guix/build/download.scm:182:15: warning: possibly unbound variable 
`make-certificate-credentials'
;;; ./guix/build/download.scm:191:20: warning: possibly unbound variable 
`x509-certificate-format/pem'
;;; ./guix/build/download.scm:199:2: warning: possibly unbound variable 
`session-peer-certificate-chain'
;;; ./guix/build/download.scm:201:5: warning: possibly unbound variable 
`import-x509-certificate'
;;; ./guix/build/download.scm:201:5: warning: possibly unbound variable 
`x509-certificate-format/der'
;;; ./guix/build/download.scm:210:10: warning: possibly unbound variable 
`x509-certificate-matches-hostname?'
;;; ./guix/build/download.scm:215:2: warning: possibly unbound variable 
`peer-certificate-status'
;;; ./guix/build/download.scm:234:13: warning: possibly unbound variable 
`certificate-status->string'
;;; ./guix/build/download.scm:229:20: warning: possibly unbound variable 
`x509-certificate-dn'
;;; ./guix/build/download.scm:246:18: warning: possibly unbound variable 
`make-session'
;;; ./guix/build/download.scm:246:18: warning: possibly unbound variable 
`connection-end/client'
;;; ./guix/build/download.scm:255:8: warning: possibly unbound variable 
`set-session-server-name!'
;;; ./guix/build/download.scm:255:8: warning: possibly unbound variable 
`server-name-type/dns'
;;; ./guix/build/download.scm:259:4: warning: possibly unbound variable 
`set-session-transport-fd!'
;;; ./guix/build/download.scm:260:4: warning: possibly unbound variable 
`set-session-default-priority!'
;;; ./guix/build/download.scm:266:4: warning: possibly unbound variable 
`set-session-priorities!'
;;; ./guix/build/download.scm:268:4: warning: possibly unbound variable 
`set-session-credentials!'
;;; ./guix/build/download.scm:272:34: warning: possibly unbound variable 
`make-certificate-credentials'
;;; ./guix/build/download.scm:280:8: warning: possibly unbound variable 
`handshake'
;;; ./guix/build/download.scm:282:15: warning: possibly unbound variable 
`error/warning-alert-received'
;;; ./guix/build/download.scm:287:23: warning: possibly unbound variable 
`alert-description->string'
;;; ./guix/build/download.scm:287:50: warning: possibly unbound variable 
`alert-get'
;;; ./guix/build/download.scm:288:15: warning: possibly unbound variable 
`handshake'
;;; ./guix/build/download.scm:303:18: warning: possibly unbound variable 
`session-record-port'
;;; Failed to autoload make-session in (gnutls):
;;; missing interface for module (gnutls)
;;; Failed to autoload make-session in (gnutls):
;;; missing interface for module (gnutls)
;;; Failed to autoload connection-end/client in (gnutls):
;;; missing interface for module (gnutls)
;;; ./guix/discovery.scm:89:22: warning: non-literal format string
;;; ./guix/ui.scm:168:5: warning: non-literal format string
;;; ./guix/ui.scm:313:2: warning: non-literal format string
;;; ./guix/ui.scm:331:22: warning: non-literal format string
;;; ./guix/ui.scm:359:13: warning: non-literal format string
;;; ./guix/ui.scm:352:7: warning: non-literal format string
;;; ./guix/ui.scm:347:11: warning: non-literal 

bug#22629: [PATCH 0/4] 'guix pull' produces a self-contained Guix

[Fis Trivial]

>
>>>  The result of running ‘guix pull’ is a “profile” available under
>>>   ‘~/.config/guix/current’ containing the latest Guix.  Thus, make sure to
>>>   add it to the beginning of your search path so that you use the latest
>>>   version, and similarly for the Info manual (*note Documentation::):
>>>
>>>export PATH="$HOME/.config/guix/current/bin:$PATH"
>>>export INFOPATH="$HOME/.config/guix/current/share/info:$INFOPATH"
>>>
>>
>> This sounds like something could be done by guix itself, choosing the
>> right profile path by $HOME. Since guix has absolute control about this
>> piece of information?
>
> I think it would be bad for Guix to modify your ~/.bashrc directly, so
> it’s better to let users do that.
>

Well, I mean a wrapper script looks similar to this in /usr/bin or
/usr/local/bin:

  #!/path/to/store/bash
  # A wrapper named guix lives in /usr/bin/ or /usr/local/bin
  exec $HOME/.config/guix/current/bin/guix "$@"

I might be wrong, please forgive my poor knowledge.

> GuixSD will have the right PATH and INFOPATH by default, though.
>
>>> Caveats:
>>>
>>>   1. The ~/.config/guix/current profile really lives there.  That is,
>>>  unlike ~/.guix-profile, it’s not in /var/guix/profiles/per-user.
>>>  That could be an issue for cluster setups where home directories
>>>  are not scanned by the Guix GC.  Cluster folks, please tell me!
>>
>> What does that mean? We have a guix directory under $HOME/.config,
>> inside there's a symlink to /gnu/store/...-guix-. Does "really
>> lives there" mean the new profile is not a symlink but a concrete
>> directory or hard link?
>
> Please see how ~/.guix-profile and
> /var/guix/profiles/per-user/$USER/guix-profile work together.  Basically
> generations show up in /var/guix/profiles, whereas ~/.guix-profile is a
> fixed symlink.
>

Thanks for the explanation, but running $ls shows:

lrwxrwxrwx. 1 fis fis 44 Mar 28 16:41 .guix-profile -> 
/var/guix/profiles/per-user/fis/guix-profile

You are talking about the same directory
"/var/guix/profiles/per-user/$USER/guix-profile" and "~/.guix-profile".

That's fine, I am waiting for the new feature to land home in my
device anyway. I will inspect more closely then.

>>>   3. C++ code is not built.  I wonder which will come first: getting rid
>>>  of the C++ code, or building it?  :-)
>>>
>> In the future world, how do we update guix daemon? Is't still running
>> guix pull && guix package -u under root user?
>
> In the future world, ‘guix pull’ updates everything: client-side and
> daemon.  Currently it’s still client-side only.
>

That sounds really nice! Thanks!

> HTH!
>

Interesting, you never run out of acronym :). If it means "hope this
help", sure, thanks for the reply.

> Ludo’.

bug#22629: [PATCH 0/4] 'guix pull' produces a self-contained Guix

[Fis Trivial]

Hi, first of all, thanks for the improvement. It's really exciting know
progress in guix.

But I have a few questions around this change. Just curiosity. :)

> Hello Guix!
>
> Here is the “new” ‘guix pull’ that we discussed notably in this thread:
>
>   https://bugs.gnu.org/22629
>
> The major difference is that instead of just building a bunch of modules
> and putting them under ~/.config/guix/latest, it now produces a
> standalone package (with bin/guix, share/info/guix.info, etc.) and puts
> it in a profile under ~/.config/guix/current.  Quoth the manual:
>
>  The result of running ‘guix pull’ is a “profile” available under
>   ‘~/.config/guix/current’ containing the latest Guix.  Thus, make sure to
>   add it to the beginning of your search path so that you use the latest
>   version, and similarly for the Info manual (*note Documentation::):
>
>export PATH="$HOME/.config/guix/current/bin:$PATH"
>export INFOPATH="$HOME/.config/guix/current/share/info:$INFOPATH"
>

This sounds like something could be done by guix itself, choosing the
right profile path by $HOME. Since guix has absolute control about this
piece of information?

>  This ‘~/.config/guix/current’ profile works like any other profile
>   created by ‘guix package’ (*note Invoking guix package::).  That is, you
>   can list generations, roll back to the previous generation—i.e., the
>   previous Guix—and so on:
>
>$ guix package -p ~/.config/guix/current -l
>Generation 1   May 25 2018 10:06:41
>  guix 221951a out 
> /gnu/store/i4dfk7vw5k112s49jrhl6hwsfnh6wr7l-guix-221951af4
>
>Generation 2   May 27 2018 19:07:47
> + guix2fbae00 out 
> /gnu/store/44cv9hyvxg34xf5kblf5dz57hc52y4bm-guix-2fbae006f
> - guix221951a out 
> /gnu/store/i4dfk7vw5k112s49jrhl6hwsfnh6wr7l-guix-221951af4
>
>Generation 3   May 30 2018 16:11:39(current)
> + guixa076f19 out 
> /gnu/store/332czkicwwg6lc3x4aqbw5q2mq12s7fj-guix-a076f1990
> - guix2fbae00 out 
> /gnu/store/44cv9hyvxg34xf5kblf5dz57hc52y4bm-guix-2fbae006f
>$ guix package -p ~/.config/guix/current --roll-back
>switched from generation 3 to 2
>
>> There are two requirements it fulfills in terms of compatibility:
>
>   1. The modified ‘build-aux/build-self.scm’ still does the right thing
>  when evaluated by an “old” Guix—that is, it produces a bunch of
>  modules for use in ~/.config/guix/latest as before.
>
>   2. The modified ‘guix pull’ produces ~/.config/guix/current even when
>  invoked on a commit of a past Guix.  That is, it automatically
>  produces a ‘guix’ command using the modules returned by the old
>  ‘build-self.scm’.
>
>
> We could add ‘guix pull’ options for convenient: ‘--roll-back’,
> ‘--profile’, etc.
>

Nice~

> Going forward, additional “channels” could be presented as entries in
> the ~/.config/guix/current manifest.
>
> Caveats:
>
>   1. The ~/.config/guix/current profile really lives there.  That is,
>  unlike ~/.guix-profile, it’s not in /var/guix/profiles/per-user.
>  That could be an issue for cluster setups where home directories
>  are not scanned by the Guix GC.  Cluster folks, please tell me!

What does that mean? We have a guix directory under $HOME/.config,
inside there's a symlink to /gnu/store/...-guix-. Does "really
lives there" mean the new profile is not a symlink but a concrete
directory or hard link?
>
>   2. The translated Info manual is not built.  Julien: could you turn
>  the big ‘xref_command’ in a script or something that we can more
>  easily reuse in (guix self)?
>
>   3. C++ code is not built.  I wonder which will come first: getting rid
>  of the C++ code, or building it?  :-)
>
In the future world, how do we update guix daemon? Is't still running
guix pull && guix package -u under root user?

bug#31637: PyQt is broken.

[Fis Trivial]

$ guix --version

guix (GNU Guix) 6fe165770539a4551b303dc5cd52db6c51c7604a

Here is the last part of build log:

make[1]: Entering directory 
'/tmp/guix-build-python-pyqt-5.9.drv-0/PyQt5_gpl-5.9/QtTest'
g++ -c -pipe -O2 -std=gnu++11 -fno-exceptions -Wall -W -D_REENTRANT -fPIC 
-DSIP_PROTECTED_IS_PUBLIC -Dprotected=public -DQT_NO_EXCEPTIONS -DQT_NO_DEBUG 
-DQT_PLUGIN -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_TESTLIB_LIB -DQT_CORE_LIB 
-DQT_TESTCASE_BUILDDIR='"/tmp/guix-build-python-pyqt-5.9.drv-0/PyQt5_gpl-5.9/QtTest"'
 -I. -I. -isystem 
/gnu/store/3lkypf5wnsnvkaidhw0pv7k3yjfh1r9g-python-3.6.3/include/python3.6m 
-isystem /gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/include/qt5 
-isystem 
/gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/include/qt5/QtWidgets 
-isystem 
/gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/include/qt5/QtGui 
-isystem 
/gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/include/qt5/QtTest 
-isystem 
/gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/include/qt5/QtCore 
-I. -isystem 
/gnu/store/88vpd91676yna0zrix1shvqvvh4nx21a-libdrm-2.4.91/include/libdrm 
-I/gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/lib/qt5/mkspecs/linux-g++
 -o sipQtTestQSignalSpy.o sipQtTestQSignalSpy.cpp
g++ -c -pipe -O2 -std=gnu++11 -fno-exceptions -Wall -W -D_REENTRANT -fPIC 
-DSIP_PROTECTED_IS_PUBLIC -Dprotected=public -DQT_NO_EXCEPTIONS -DQT_NO_DEBUG 
-DQT_PLUGIN -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_TESTLIB_LIB -DQT_CORE_LIB 
-DQT_TESTCASE_BUILDDIR='"/tmp/guix-build-python-pyqt-5.9.drv-0/PyQt5_gpl-5.9/QtTest"'
 -I. -I. -isystem 
/gnu/store/3lkypf5wnsnvkaidhw0pv7k3yjfh1r9g-python-3.6.3/include/python3.6m 
-isystem /gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/include/qt5 
-isystem 
/gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/include/qt5/QtWidgets 
-isystem 
/gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/include/qt5/QtGui 
-isystem 
/gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/include/qt5/QtTest 
-isystem 
/gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/include/qt5/QtCore 
-I. -isystem 
/gnu/store/88vpd91676yna0zrix1shvqvvh4nx21a-libdrm-2.4.91/include/libdrm 
-I/gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/lib/qt5/mkspecs/linux-g++
 -o sipQtTestQTest.o sipQtTestQTest.cpp
g++ -c -pipe -O2 -std=gnu++11 -fno-exceptions -Wall -W -D_REENTRANT -fPIC 
-DSIP_PROTECTED_IS_PUBLIC -Dprotected=public -DQT_NO_EXCEPTIONS -DQT_NO_DEBUG 
-DQT_PLUGIN -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_TESTLIB_LIB -DQT_CORE_LIB 
-DQT_TESTCASE_BUILDDIR='"/tmp/guix-build-python-pyqt-5.9.drv-0/PyQt5_gpl-5.9/QtTest"'
 -I. -I. -isystem 
/gnu/store/3lkypf5wnsnvkaidhw0pv7k3yjfh1r9g-python-3.6.3/include/python3.6m 
-isystem /gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/include/qt5 
-isystem 
/gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/include/qt5/QtWidgets 
-isystem 
/gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/include/qt5/QtGui 
-isystem 
/gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/include/qt5/QtTest 
-isystem 
/gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/include/qt5/QtCore 
-I. -isystem 
/gnu/store/88vpd91676yna0zrix1shvqvvh4nx21a-libdrm-2.4.91/include/libdrm 
-I/gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/lib/qt5/mkspecs/linux-g++
 -o sipQtTestQTestQTouchEventSequence.o sipQtTestQTestQTouchEventSequence.cpp
g++ -c -pipe -O2 -std=gnu++11 -fno-exceptions -Wall -W -D_REENTRANT -fPIC 
-DSIP_PROTECTED_IS_PUBLIC -Dprotected=public -DQT_NO_EXCEPTIONS -DQT_NO_DEBUG 
-DQT_PLUGIN -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_TESTLIB_LIB -DQT_CORE_LIB 
-DQT_TESTCASE_BUILDDIR='"/tmp/guix-build-python-pyqt-5.9.drv-0/PyQt5_gpl-5.9/QtTest"'
 -I. -I. -isystem 
/gnu/store/3lkypf5wnsnvkaidhw0pv7k3yjfh1r9g-python-3.6.3/include/python3.6m 
-isystem /gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/include/qt5 
-isystem 
/gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/include/qt5/QtWidgets 
-isystem 
/gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/include/qt5/QtGui 
-isystem 
/gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/include/qt5/QtTest 
-isystem 
/gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/include/qt5/QtCore 
-I. -isystem 
/gnu/store/88vpd91676yna0zrix1shvqvvh4nx21a-libdrm-2.4.91/include/libdrm 
-I/gnu/store/xgpwah2hppghgc7c09jp643ddm2lfjj5-qtbase-5.11.0/lib/qt5/mkspecs/linux-g++
 -o sipQtTestcmodule.o sipQtTestcmodule.cpp
/tmp/guix-build-python-pyqt-5.9.drv-0/PyQt5_gpl-5.9/QtTest/sipQtTestQTest.cpp: 
In function ‘PyObject* meth_QTest_waitForEvents(PyObject*, PyObject*)’:
/tmp/guix-build-python-pyqt-5.9.drv-0/PyQt5_gpl-5.9/QtTest/sipQtTestQTest.cpp:278:14:
 error: ‘waitForEvents’ is not a member of ‘QTest’
make[1]: *** [Makefile:545: sipQtTestQTest.o] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory 
'/tmp/guix-build-python-pyqt-5.9.drv-0/PyQt5_gpl-5.9/QtTest'
make: *** [Makefile:596: 

bug#31294: Failed building dependencies for guix.

[Fis Trivial]

Ludovic Courtès writes:

> Hi,
>
> Fis Trivial <ybbs.da...@hotmail.com> skribis:
>
>> Ludovic Courtès writes:
>
> [...]
>
>>> Could you paste /gnu/store/5y6mkv079xq5hnfajxfwky0kfc6ffy3p-info-dir.drv ?
>
> [...]
>
>> "/gnu/store/32qhdh8q4ba9lzp20495lw3a4cx0p3mp-guile-2.2.3/bin/guile",["--no-auto-compile","/gnu/store/mpy5w5gprs1ymrl3kwhqwr2jvnkdnvh7-info-dir-builder"],[("allowSubstitutes","0"),("out","/gnu/store/dpc817mql6764c6banrljn8lyjjjaf66-info-dir"),("preferLocalBuild","1")])
>
> As in Chris’s case, there’s no -L or -C here.
>
>>> Also, could you post ~/.config/guix/latest/guix/profiles.go and
>>> /run/current-system/profile/lib/guile/2.2/site-ccache/guix/profiles.go ?
>>> (Perhaps you’ll need to gzip them to be sure.)
>>>
>>
>> I couldn't find
>> /run/current-system/profile/lib/guile/2.2/site-ccache/guix/profiles.go
>> you are talking about, I did `find . -iname "profiles.go"` in /run/ as
>> root but didn't find the file you are talking about, not even the
>> directory "current-system". But ~/.config/guix/latest/guix/profiles.go
>> is attached in the mail.
>
> Apparently the profiles.go you sent is correct.
>
> To find out where the faulty profiles.go is, could you:
>
>   1. Run ‘guix environment guix’ in the environment that triggers the
>  error, but run it under ‘strace’:
>
>strace -f -o log guix environment guix
>
>   2. grep that ‘log’ file along these lines:
>
>grep 'open.*guix/profiles\.go.*= [0-9]' log
>
>   3. gzip that profiles.go file and send it.
>
> Thanks in advance,
> Ludo’.

Send as attachment.



profiles.tar.xz
Description: profiles.xz

bug#31294: Failed building dependencies for guix.

[Fis Trivial]

Ludovic Courtès writes:

> Hi,
>
> Fis Trivial <ybbs.da...@hotmail.com> skribis:
>
>> Use following steps to reproduce:
>> $ env -i bash --norc --noprofile --login
>> $ guix environment guix
>>
>> Error message:
>>
>> The following derivations will be built:
>>/gnu/store/c53mj37x2dnrgmrpagpv9l5c2ghly2hy-profile.drv
>>/gnu/store/vpvx01j2qs31lfix131n1akwdjwf5s4z-xdg-desktop-database.drv
>>/gnu/store/hr8xa2inki6lfbn8v9jfgmygbxygszs2-xdg-mime-database.drv
>>/gnu/store/5y6mkv079xq5hnfajxfwky0kfc6ffy3p-info-dir.drv
>>/gnu/store/95glrzk2y6p6b3z7hlmdignzzvxjvi2r-manual-database.drv
>> Backtrace:
>>   10 (primitive-load "/gnu/store/mpy5w5gprs1ymrl3kwhqwr2jvnk?")
>> In ice-9/eval.scm:
>>721:20  9 (primitive-eval (begin (use-modules (guix build #) ?) ?))
>> In ice-9/psyntax.scm:
>>   1235:36  8 (expand-top-sequence ((begin (use-modules (# # ?) ?) ?)) ?)
>>   1182:24  7 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
>>   1182:24  6 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
>>285:10  5 (parse _ (("placeholder" placeholder)) (()) _ c (eval) ?)
>> In ice-9/boot-9.scm:
>>   3365:20  4 (process-use-modules _)
>>222:17  3 (map1 (((guix build utils)) ((srfi srfi-1)) ((srfi ?)) ?))
>>   3366:31  2 (_ ((guix build utils)))
>>2791:6  1 (resolve-interface _ #:select _ #:hide _ #:prefix _ # _ ?)
>> In unknown file:
>>0 (scm-error misc-error #f "~A ~S" ("no code for modu?" ?) ?)
>>
>> ERROR: In procedure scm-error:
>> no code for module (guix build utils)
>> builder for `/gnu/store/5y6mkv079xq5hnfajxfwky0kfc6ffy3p-info-dir.drv' 
>> failed with exit code 1
>
> This looks like <https://bugs.gnu.org/28144>, which we don’t understand
> yet.
>
> (Most likely changing the Bash environment just led you to ignore
> ~/.config/guix/latest (or vice versa), thereby leading you to use a
> different set of Guix compiled modules.)
>
> Could you paste /gnu/store/5y6mkv079xq5hnfajxfwky0kfc6ffy3p-info-dir.drv ?
>

Derive([("out","/gnu/store/dpc817mql6764c6banrljn8lyjjjaf66-info-dir","","")],[("/gnu/store/0bfjq1ffy0m91frzsq1n4jqqg1hwx4v7-guile-2.2.3.drv",["out"]),("/gnu/store/0sr6a7lj72vb3cqx2gsdk3lxi2qr8hv1-file-5.32.drv",["out"]),("/gnu/store/13lpzxlf846i008qbiw85n3vhf9yvplq-sqlite-3.21.0.drv",["out"]),("/gnu/store/2jj26rl41f2352kl0iq8d57i6lgyfn5c-automake-1.15.1.drv",["out"]),("/gnu/store/460grihfmshw7z0bnqq09hys0hhpimy9-libtasn1-4.12.drv",["out"]),("/gnu/store/4k0p2qgjf121gd1jvb433jjlxb951iw4-grep-3.1.drv",["out"]),("/gnu/store/4m259i6f83awbdi09gn3v8skrsflcdzx-bash-minimal-4.4.12.drv",["out"]),("/gnu/store/509g2r09spbspn5imd42nsqx402jbsjf-guile-2.2.3.drv",["out"]),("/gnu/store/811pfvhj0gnrv8fqw4r6p6niqg87aphv-ld-wrapper-0.drv",["out"]),("/gnu/store/9n95j6vzy2xgzwm2kp04lyrdwz2ccgxm-util-linux-2.31.drv",["out"]),("/gnu/store/9nmwnbs9jndfama90x4i9v5150i64xf0-sed-4.4.drv",["out"]),("/gnu/store/ackbyqpplc6yr5hk68snawx4bmrygn6f-xz-5.2.3.drv",["out"]),("/gnu/store/ajxj7xlidhn1wf21kzvzj0z6p2srz8j3-bzip2-1.0.6.drv",["out"]),("/gnu/store/aw7mmwdw1qs25c8cryasi6vwqxwpa0gy-make-4.2.1.drv",["out"]),("/gnu/store/bczgczvb3nwcypk67z9j67np7xgf6b4c-glibc-utf8-locales-2.26.105-g0890d5379c.drv",["out"]),("/gnu/store/bfadqq933hs8f05213z8wnawd1cga6h2-guile-json-0.6.0.drv",["out"]),("/gnu/store/bh5pivpjk0gxnq1nzpkx3vbmwyak3qxa-guile-git-0.0-6.36f93c1.drv",["out"]),("/gnu/store/c2z8m9sagz3d2m57irhpzg86bqh2z795-graphviz-2.40.1.drv",["out"]),("/gnu/store/cjrz5r8yjghj8lwgxsqqa259c72pdib6-libltdl-2.4.6.drv",["out"]),("/gnu/store/czk2xigxxwkbyvlp112k4y61igibab4y-gzip-1.8.drv",["out"]),("/gnu/store/d8y0rbsicxkhw0dgxzj2idm1bfd98bxz-libgc-7.6.0.drv",["out"]),("/gnu/store/dfj9qsrhl9xd2997wqg9wqyk7xc47fin-gcc-5.5.0.drv",["out"]),("/gnu/store/fg9jyyrc0fs8l34wasw3pahhwp1pbky9-zlib-1.2.11.drv",["out"]),("/gnu/store/fld0ygyvd89py4kai9vnkvv70gp7mhaz-pkg-config-0.29.2.drv",["out"]),("/gnu/store/g96gl1d58llibr3q8l3l36bpkm4vv4c9-texinfo-6.5.drv",["out"]),("/gnu/store/h2imfnqll253wkz2dpig595bvkpcpii0-po4a-0.47.drv",["out"]),("/gnu/store/hbi3gqpfbvxc9r9y8w2yb923j5dm2cxi-gzip-1.8.drv",["out"]),("/gnu/store/hzj9vs4hgqdw2s

bug#30921: Jupyter uses the wrong Python.

[Fis Trivial]

Ricardo Wurmus writes:

> Fis Trivial <ybbs.da...@hotmail.com> writes:
>
>> When running jupyter, it seems that the python in "/usr/bin/python"
>> instead of the one in store is used. Here is the complete logging of
>> jupyter console output, notice those line in the middle, where displaying:
>> "/usr/bin/python: No module named ipykernel_launcher"
>
> I wonder if that’s by design.  As far as I understand Jupyter can be
> used with many different kernels, including different versions of
> Python.  This means that we may not limit it to just a single version of
> Python at build time.
>
> Is this correct?
>

Actually the only command I know about jupyter is how to open a
notebook :) . But it asks me to restart the kernel again and again in
browser. And according to the console, it seems that jupyter couldn't
find the needed kernel because the kernel is installed in guix store,
not in normal system path, but jupyter itself is ran by system
python other than the one installed in guix store.

And, maybe I am wrong, packages that installed by guix should never use
software not in the store, right?


> I do agree, though, that the default doesn’t seem right.  As long as a
> user can override the kernel to use a different Python than the one we
> configured at build time, I think we should default to the current
> version of Python in Guix.

bug#30921: Jupyter uses the wrong Python.

[Fis Trivial]

When running jupyter, it seems that the python in "/usr/bin/python"
instead of the one in store is used. Here is the complete logging of
jupyter console output, notice those line in the middle, where displaying:
"/usr/bin/python: No module named ipykernel_launcher"

--
/gnu/store/k2y0d2rp57pnl90lxqgs5i7ywywrn456-python-traitlets-4.2.0/lib/python3.6/site-packages/traitlets/config/configurable.py:74:
 RuntimeWarning: Passing unrecoginized arguments to 
super(ConfigManager).__init__(config_dir='/home/fis/.jupyter/nbconfig').
object.__init__() takes no parameters
This error will be raised in a future release of traitlets.
  super(Configurable, self).__init__(**kwargs)
[I 14:48:57.236 NotebookApp] Serving notebooks from local directory: 
/home/fis/Others/git-repos/machine-learning/AIMA/aima-python
[I 14:48:57.237 NotebookApp] 0 active kernels 
[I 14:48:57.237 NotebookApp] The Jupyter Notebook is running at: 
http://localhost:/
[I 14:48:57.237 NotebookApp] Use Control-C to stop this server and shut down 
all kernels (twice to skip confirmation).
[W 14:49:11.606 NotebookApp] Notebook mdp.ipynb is not trusted
[W 14:49:11.638 NotebookApp] 404 GET 
/nbextensions/widgets/notebook/js/extension.js?v=20180324144856 (::1) 5.27ms 
referer=http://localhost:/notebooks/mdp.ipynb
[W 14:49:11.919 NotebookApp] Deprecated files/ URL: files/images/mdp-a.png
[I 14:49:11.920 NotebookApp] 302 GET /notebooks/files/images/mdp-a.png (::1) 
1.02ms
[I 14:49:12.687 NotebookApp] 302 GET /notebooks/images/grid_mdp.jpg (::1) 0.90ms
[I 14:49:12.689 NotebookApp] 302 GET /notebooks/images/grid_mdp_agent.jpg (::1) 
0.88ms
[I 14:49:12.955 NotebookApp] 302 GET /notebooks/images/-0.04.jpg (::1) 0.87ms
[I 14:49:13.023 NotebookApp] 302 GET /notebooks/images/-0.4.jpg (::1) 0.89ms
[I 14:49:13.124 NotebookApp] 302 GET /notebooks/images/-4.jpg (::1) 0.89ms
[I 14:49:13.210 NotebookApp] 302 GET /notebooks/images/4.jpg (::1) 0.91ms
[I 14:49:13.264 NotebookApp] 302 GET /notebooks/images/ge0.jpg (::1) 0.89ms
[I 14:49:13.265 NotebookApp] 302 GET /notebooks/images/ge1.jpg (::1) 0.80ms
[I 14:49:13.266 NotebookApp] 302 GET /notebooks/images/ge4.jpg (::1) 0.77ms
[I 14:49:13.267 NotebookApp] 302 GET /notebooks/images/ge2.jpg (::1) 0.77ms
[I 14:49:13.298 NotebookApp] Kernel started: 
9d5e4be9-15e1-488d-b1a2-408c229eb83c
/usr/bin/python: No module named ipykernel_launcher
[W 14:49:13.386 NotebookApp] 404 GET 
/static/components/MathJax/jax/element/mml/optable/BasicLatin.js?rev=2.6.0 
(::1) 1.79ms referer=http://localhost:/notebooks/mdp.ipynb
[I 14:49:16.299 NotebookApp] KernelRestarter: restarting kernel (1/5)
/usr/bin/python: No module named ipykernel_launcher
[I 14:49:19.305 NotebookApp] KernelRestarter: restarting kernel (2/5)
/usr/bin/python: No module named ipykernel_launcher
[I 14:49:22.314 NotebookApp] KernelRestarter: restarting kernel (3/5)
/usr/bin/python: No module named ipykernel_launcher
[W 14:49:23.474 NotebookApp] Timeout waiting for kernel_info reply from 
9d5e4be9-15e1-488d-b1a2-408c229eb83c
[I 14:49:25.324 NotebookApp] KernelRestarter: restarting kernel (4/5)
WARNING:root:kernel 9d5e4be9-15e1-488d-b1a2-408c229eb83c restarted
/usr/bin/python: No module named ipykernel_launcher
[W 14:49:28.337 NotebookApp] KernelRestarter: restart failed
[W 14:49:28.337 NotebookApp] Kernel 9d5e4be9-15e1-488d-b1a2-408c229eb83c died, 
removing from map.
ERROR:root:kernel 9d5e4be9-15e1-488d-b1a2-408c229eb83c restarted failed!
[W 14:49:28.359 NotebookApp] Kernel deleted before session
[W 14:49:28.360 NotebookApp] 410 DELETE 
/api/sessions/d6e551c2-84d2-4de4-bb25-1db37e4763c4 (::1) 1.22ms 
referer=http://localhost:/notebooks/mdp.ipynb
--


I'm currently running guix on top of fedora 27 x86_64, for guix version:
$ guix --version

guix (GNU Guix) 282e48eae92b1988fc7fddbf206030ccf1623728
Copyright (C) 2018 the Guix authors
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

bug#30898: Warning "No such language bytecode" when pulling guix.

[Fis Trivial]

$ guix pull

---
Updating from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
Building from Git commit e2f9847be0d1fcde201b3ec01f68a9cbdda230a0...
The following derivation will be built:
   /gnu/store/15ncl8zii4kvixwyqqm94v6nzvc3j9z4-guix-latest.drv
copying and compiling to 
'/gnu/store/6kp539k2839870w3r7cmg5j8ryj5w98m-guix-latest' with Guile 2.2.3...
loading...   25.8% of 675 filesrandom seed for tests: 1521662834
compiling... 89.9% of 675 filesIn thread:
no such language bytecode
In thread:
In procedure lambda: bad lambda
compiling... 90.1% of 675 filesIn thread:
no such language scheme
compiling... 90.2% of 675 filesIn thread:
no such language scheme
compiling... 90.4% of 675 filesIn thread:
no such language scheme
compiling... 90.5% of 675 filesIn thread:
no such language scheme
compiling... 90.7% of 675 filesIn thread:
no such language scheme
compiling... 90.8% of 675 filesIn thread:
no such language scheme
compiling...100.0% of 675 files

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
updated GNU Guix successfully deployed under `/home/fis/.config/guix/latest'
---

The build was successful, but the I think I should report it for those
error message.


I'm currently runing guix on Fedora 27, x86_64.
This was actually the forth time of successive pull, due to previous
failures, which is mentioned in another bug report[1]:
---
compiling...100.0% of 675 files
Backtrace:
Exception thrown while printing backtrace:
In procedure public-lookup: Module named (system repl debug) does not exist
---

[1]:https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30602

bug#30229: Python modules installed by pip in virtualenv can't find shared objects.

[Fis Trivial]

> 
> In general, though, I recommend using Guix for package management and
> development instead of virtualenv and pip.
> 
I understand the importance for having a self-contained dependency graph.

After trying guix a few months, I came to realize that, at the a theoretical
level, the environment variables are not treated as part of the dependency
graph in the Guix world. Dangling environment variables happens, and can not
be solved by installing everything with guix(1).

I really hope that we can come up with some methods to solve these problems
in a systematical way. I will keep reporting bugs caused by environment
variables, hoping that it might be helpful in future development.


[1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30093

bug#30229: Python modules installed by pip in virtualenv can't find shared objects.

[Fis Trivial]

When a python module needs to load a dynamic shared object, it looks in the
path provided by *LD_LIBRARY_PATH*(1), but guix doesn't modify this environment
variable to export the needed path for python.

* Backtrace
In my case, it's lightgbm (installed by pip), needs libgomp.so from gcc:lib for
openmp support. Here is the backtrace:

--8<---cut here---start->8---
Traceback (most recent call last):
  File "ex1.py", line 5, in 
import lightgbm as lgb
  File 
"/home/fis/Workspace/tianchi/medical_treatment/lib/python3.5/site-packages/lightgbm/__init__.py",
 line 8, in 
from .basic import Booster, Dataset
  File 
"/home/fis/Workspace/tianchi/medical_treatment/lib/python3.5/site-packages/lightgbm/basic.py",
 line 32, in 
_LIB = _load_lib()
  File 
"/home/fis/Workspace/tianchi/medical_treatment/lib/python3.5/site-packages/lightgbm/basic.py",
 line 27, in _load_lib
lib = ctypes.cdll.LoadLibrary(lib_path[0])
  File 
"/gnu/store/jb3n0bsdpkhvyb8y70jyr8fcx8fqssr9-python-3.5.3/lib/python3.5/ctypes/__init__.py",
 line 425, in LoadLibrary
return self._dlltype(name)
  File 
"/gnu/store/jb3n0bsdpkhvyb8y70jyr8fcx8fqssr9-python-3.5.3/lib/python3.5/ctypes/__init__.py",
 line 347, in __init__
self._handle = _dlopen(self._name, mode)
OSError: libgomp.so.1: cannot open shared object file: No such file or directory
--8<---cut here---end--->8---

* Reproduce
To install lightgbm, simply use `pip install lightgbm`(in virtualenv).
Then in python shell:
import lightgbm as lgb

* Ad-hoc
export LD_LIBRARY_PATH=~/.guix-profile/lib:$LD_LIBRARY_PATH


[1]: https://stackoverflow.com/a/1100016

bug#30093: Installing python-ipython breaks Gnome on Fedora.

[Fis Trivial]

>
> so I
> still think it might be best to deal with the problems on a case by case
> basis.
>

I tried to find out what would Fedora set *GI_TYPELIB_PATH* if guix didn't.
It turns out, nothing. If I comment out the line containing *GI_TYPELIB_PATH*
in ~/.guix-profile/etc/profile, the variable won't be exist.
Is there any suggestion for what I can do, to let guix have this variable, while
Fedora wouldn't see it?

bug#30121: python-matplotlib broken.

[Fis Trivial]

>
> Do you have a matplotlibrc file that sets a Qt-based backend? The default 
> backend is TkAgg, which does not require Qt. (Note that PySide is a Qt 
> interface for Python.)
> 
I myself have never created such a file.

I searched home with `find . -iname "*matplotlib*"`, didn't find the rc file
you mentioned except in some virtualenvs. But that should not be related.

By searching /etc as root, didn't find it either.

bug#30122: python-pygobject with gtk+ broken.

[Fis Trivial]

* Steps to reproduce:
Install python-pygobject with guix: `guix package -i python-pygobject`
Install gtk+ with guix: `guix package -i gtk+`

$ python
>>> from gi.repository import Gtk

* Full message
--8<---cut here---start->8---
Python 3.5.3 (default, Jan  1 1970, 00:00:01)
[GCC 5.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from gi.repository import Gtk
/home/fis/.guix-profile/lib/python3.5/site-packages/gi/module.py:178: Warning: 
cannot register existing type 'AtkImplementorIface'
  g_type = info.get_g_type()
/home/fis/.guix-profile/lib/python3.5/site-packages/gi/module.py:212: Warning: 
g_type_get_qdata: assertion 'node != NULL' failed
  type_ = g_type.pytype
/home/fis/.guix-profile/lib/python3.5/site-packages/gi/types.py:235: Warning: 
cannot register existing type 'AtkImplementorIface'
  register_interface_info(cls.__info__.get_g_type())
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 969, in _find_and_load
  File "", line 958, in _find_and_load_unlocked
  File "", line 664, in _load_unlocked
  File "", line 634, in _load_backward_compatible
  File "/home/fis/.guix-profile/lib/python3.5/site-packages/gi/importer.py", 
line 146, in load_module
dynamic_module = load_overrides(introspection_module)
  File 
"/home/fis/.guix-profile/lib/python3.5/site-packages/gi/overrides/__init__.py", 
line 125, in load_overrides
override_mod = importlib.import_module(override_package_name)
  File 
"/gnu/store/h29ggyz1wsmmk220gy811hy181lszz3y-python-3.5.3/lib/python3.5/importlib/__init__.py",
 line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File 
"/home/fis/.guix-profile/lib/python3.5/site-packages/gi/overrides/Gtk.py", line 
120, in 
class Widget(Gtk.Widget):
  File "/home/fis/.guix-profile/lib/python3.5/site-packages/gi/module.py", line 
183, in __getattr__
interfaces = tuple(interface for interface in 
get_interfaces_for_object(info)
  File "/home/fis/.guix-profile/lib/python3.5/site-packages/gi/module.py", line 
107, in get_interfaces_for_object
interfaces.append(getattr(module, name))
  File "/home/fis/.guix-profile/lib/python3.5/site-packages/gi/module.py", line 
222, in __getattr__
wrapper = metaclass(name, bases, dict_)
  File "/home/fis/.guix-profile/lib/python3.5/site-packages/gi/types.py", line 
235, in __init__
register_interface_info(cls.__info__.get_g_type())
TypeError: must be an interface
>>>
--8<---cut here---end--->8---

* Platform
Fedora 26 x86_64

* Version
guix (GNU Guix) bad12e839c2f7823c45aa0121f7d5c9bb70905b7


I have the script running on Fedora with dependencies built by dnf, but not 
guix.
I searched around, tried to find out what is missing.
But it doesn't seem to be a problem caused by missing packages.

bug#30121: python-matplotlib broken.

[Fis Trivial]

* Steps to reproduce:

$ python
>>> from matplotlib import pyplot

* Full message:
--8<---cut here---start->8---
Python 3.5.3 (default, Jan  1 1970, 00:00:01)
[GCC 5.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from matplotlib import pyplot
Traceback (most recent call last):
  File 
"/home/fis/.guix-profile/lib/python3.5/site-packages/matplotlib/backends/qt_compat.py",
 line 176, in 
from PySide import QtCore, QtGui, __version__, __version_info__
ImportError: No module named 'PySide'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File 
"/home/fis/.guix-profile/lib/python3.5/site-packages/matplotlib/pyplot.py", 
line 115, in 
_backend_mod, new_figure_manager, draw_if_interactive, _show = pylab_setup()
  File 
"/home/fis/.guix-profile/lib/python3.5/site-packages/matplotlib/backends/__init__.py",
 line 32, in pylab_setup
globals(),locals(),[backend_name],0)
  File 
"/home/fis/.guix-profile/lib/python3.5/site-packages/matplotlib/backends/backend_qt5agg.py",
 line 16, in 
from .backend_qt5 import QtCore
  File 
"/home/fis/.guix-profile/lib/python3.5/site-packages/matplotlib/backends/backend_qt5.py",
 line 26, in 
import matplotlib.backends.qt_editor.figureoptions as figureoptions
  File 
"/home/fis/.guix-profile/lib/python3.5/site-packages/matplotlib/backends/qt_editor/figureoptions.py",
 line 20, in 
import matplotlib.backends.qt_editor.formlayout as formlayout
  File 
"/home/fis/.guix-profile/lib/python3.5/site-packages/matplotlib/backends/qt_editor/formlayout.py",
 line 56, in 
from matplotlib.backends.qt_compat import QtGui, QtWidgets, QtCore
  File 
"/home/fis/.guix-profile/lib/python3.5/site-packages/matplotlib/backends/qt_compat.py",
 line 179, in 
"Matplotlib qt-based backends require an external PyQt4, PyQt5,\n"
ImportError: Matplotlib qt-based backends require an external PyQt4, PyQt5,
or PySide package to be installed, but it was not found.
>>>
--8<---cut here---end--->8---

* Platform
Fedora 26 x86_64

* Guix version
guix (GNU Guix) bad12e839c2f7823c45aa0121f7d5c9bb70905b7

bug#29824: Meson 0.44.0 is broken with guix.

[Fis Trivial]

> or
> 
> #+BEGIN_SRC python
> import os
> os.environ['PYTHONPATH']="/gnu/store/.../site-packages${PYTHONPATH:+:}$PYTHONPATH"
> exec(compile(
> open(
> 
> "/gnu/store/n53zdnl4l3gm9sg15bfwxp0wdrwrvhg4-meson-0.44.0/bin/.meson-real".read(),
> 
> "/gnu/store/n53zdnl4l3gm9sg15bfwxp0wdrwrvhg4-meson-0.44.0/bin/.meson-real",
> 'exec'
> )))
> #+END_SRC
> 
Sorry about that, this section is wrong. Here is the correct one. Be careful 
with the "..."
in the environ assignment. I omitted part of the path due to it's too long.

#+BEGIN_SRC python
#!/usr/bin/env python3
import os
os.environ['PYTHONPATH'] = 
"/gnu/store/.../site-packages${PYTHONPATH:+:}$PYTHONPATH"
# 
exec(open("/gnu/store/n53zdnl4l3gm9sg15bfwxp0wdrwrvhg4-meson-0.44.0/bin/.meson-real").read())
exec(compile(
open(

"/gnu/store/n53zdnl4l3gm9sg15bfwxp0wdrwrvhg4-meson-0.44.0/bin/.meson-real"
).read(),
"/gnu/store/n53zdnl4l3gm9sg15bfwxp0wdrwrvhg4-meson-0.44.0/bin/.meson-real",
'exec'
))

#+END_SRC

And the wrapper should be named as "meson", in this case.
The above code set the environment variables and execute the corresponding code
by loading it(not spawning a new process). Hence the argv will be preserved.

bug#29824: Meson 0.44.0 is broken with guix.

[Fis Trivial]

>>
>> detect_meson_py_location() assumes the executable to be called "meson"
>> or "meson.py", but in guix it currently is called ".meson-real" (see teh
>> first entry in the trace-back).
>>
>> The solution would be to get rid of the wrapper-scripts, see
>> 
>>
>> A work-around would be to substitute in file mesonbuild/mesonlib.py
>>
>> meson_command = python_command + [detect_meson_py_location()]
>>
>> by
>>
>> meson_command = python_command + ["$OUT/bin/meson"]
> 
> Sounds reasonable.  Does it work for you?  If so, could you provide a
> patch?
> 
> Ludo’.
> 

Or in this case, python script, we can change the wrapper script into something
like this:

#+BEGIN_SRC python
import os
os.environ['PYTHONPATH']="/gnu/store/.../site-packages${PYTHONPATH:+:}$PYTHONPATH"
exec(open("/gnu/store/n53zdnl4l3gm9sg15bfwxp0wdrwrvhg4-meson-0.44.0/bin/.meson-real").read())
#+END_SRC

or

#+BEGIN_SRC python
import os
os.environ['PYTHONPATH']="/gnu/store/.../site-packages${PYTHONPATH:+:}$PYTHONPATH"
exec(compile(
open(

"/gnu/store/n53zdnl4l3gm9sg15bfwxp0wdrwrvhg4-meson-0.44.0/bin/.meson-real".read(),

"/gnu/store/n53zdnl4l3gm9sg15bfwxp0wdrwrvhg4-meson-0.44.0/bin/.meson-real",
'exec'
)))
#+END_SRC

bug#30093: Installing python-ipython breaks Gnome on Fedora.

[Fis Trivial]

Please know that introducing wrapper script might cause problems like this one:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29824

bug#30093: Installing python-ipython breaks Gnome on Fedora.

[Fis Trivial]

Maybe we can Maybe we can divide those environment variables into two types:
  1. Needed directly by human. For example the *PATH* environment, we use it
 to start whatever program from the shell.
  2. Environment variables only needed by programs. For examples, the
 *PYTHONPATH*, or in this case *GI_TYPELIB_PATH*.

For _type 2_, we can try to wrap every program with a simple script, and
propagate all the needed environment variables from its dependencies to that
wrapping script. This should eliminate the need to put any of those environment
variables into ~/.guix-profile/etc/profile, guaranteeing the safety of these
variables.

But this method won't solve all the problems. For examples *XDG_DATA_DIRS* will
 be classified as one of variables that needed by human because we need to use
 it to find GUI programs with GUI shell, and it's also needed by some programs
(a script in this case):

> This sounds similar to the following bug:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26202
>
To mitigate the problem in above link, which is the problem introduced by
_type 1_ variables, maybe we can treat these environment variables differently.
When guix is updating it to a new value due to change of profile, it should
explicitly append the original value to the upgraded definition (explicitly
means writing it down in expanded form, like "/home/fis/.bin", not $HOME/.bin or
$VARIABLE_NAME). In the above bug, there is no way guix can define the
*XDG_DATA_DIRS* earlier than the distro. (You have to run the distro then
 install guix, right?). It's not perfect, but it seems to work.

I don't have any better idea for now. Does anybody know what kind of approaches
are employed by Flatpak and Snap?

bug#30093: Installing python-ipython breaks Gnome on Fedora.

[Fis Trivial]

I tried to find out which environment variable is responsible for breaking
the gnome shell by disabling them in ~/.guix-profile/etc/profile one at a time.

It turns out to be the *GI_TYPELIB_PATH*. After commenting it out in the profile
file my system works as usual.

But then, this variable is not exported by installing ipython(otherwise it will
let me know in the prompt after installation right?), so my guess would be
installing ipython brings in typelib of Gtk, then gnome used the wrong .typelib
file and crashed.

bug#30093: Installing python-ipython breaks Gnome on Fedora.

[Fis Trivial]

* Environment
I am currently running Guix on top of Fedora 26, which comes with Gnome 3.24.2

As recommended(1), I source *~/.guix-profile/etc/profile* in *~/.bash_profile*
to make all the exported variables recognized by login shell.

* Issue
After installing python-ipython with guix, guix exported the following
variables:

GUIX_GTK3_PATH
PKG_CONFIG_PATH

The next time I login, Gnome was broken, displaying nothing but a black screen,
except for Owncloud client(which is based on Qt). And all the key bindings
are gone.

So, I used tty to move the `source` command from *.bash_profile* to *.bashrc*.
After that, Gnome came back and functions as usual.


* Version
$: guix --version
guix (GNU Guix) d9a38cc255d853b2694a01b5704c1daedbb56742


[1]: https://lists.gnu.org/archive/html/help-guix/2017-05/msg00072.html

bug#29879: System platform

[Fis Trivial]

Forgot to append it.
I'm running guix on top of Fedora 26 x86_64 with GNU/Linux 
4.14.8-200.fc26.x86_64.

bug#29879: guix package search error.

[Fis Trivial]

* Version

$: guix pull

Updating from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
Building from Git commit 6b681ddda0f965d4163fbeb4b34520c91bd01f5d...
Guix already up to date



* Error and backtrace:

$: guix package --search=mutt

Backtrace:
In guix/ui.scm:
  1474:12 19 (run-guix-command _ . _)
In ice-9/boot-9.scm:
837:9 18 (catch _ _ # …)
837:9 17 (catch _ _ # …)
In guix/scripts/package.scm:
   912:10 16 (_)
770:9 15 (process-query _)
In ice-9/boot-9.scm:
837:9 14 (catch _ _ # …)
In guix/scripts/package.scm:
   772:24 13 (_)
   249:17 12 (find-packages-by-description _)
In guix/discovery.scm:
137:3 11 (fold-module-public-variables _ _ _)
In guix/combinators.scm:
45:26 10 (fold2 # …)
45:26  9 (fold2 # …)
In guix/discovery.scm:
   140:33  8 (_ # …)
In guix/scripts/package.scm:
   250:34  7 (_ # …)
In srfi/srfi-1.scm:
   466:18  6 (fold # …)
In guix/ui.scm:
  1146:13  5 (_ _ 0)
  1025:23  4 (texi->plain-text _)
In texinfo.scm:
  1131:22  3 (parse _)
   979:31  2 (loop # (*fragment*) _ _ _)
   868:21  1 (visit example # #f ((para #) #))
   675:23  0 (complete-start-command _ #)

texinfo.scm:675:23: In procedure complete-start-command:
texinfo.scm:675:23: Throw to key `parser-error' with args `(# "@-command didn't expect more args" example (".com --connect"))'.

bug#29840: guix pull failed

[Fis Trivial]

On 12/27/2017 03:14 AM, Leo Famulari wrote:
> On Sun, Dec 24, 2017 at 05:33:21PM +0000, Fis Trivial wrote:
>
> Hi, thanks for this report!
>
>> Runing `guix pull` generates the following error message:
>>
>>
>> Updating from Git repository at
>> 'https://git.savannah.gnu.org/git/guix.git'...
>> Building from Git commit b982fb1c09573f4638324d7809ec18d0c9956d11...
>> The following derivation will be built:
>>      /gnu/store/d8gx000cbyihr3x3gggnm9d61adjb0s3-guix-latest.drv
>> copying and compiling to
>> '/gnu/store/42n0q7dhq5l7yd0hd550m80zw2z256fy-guix-latest' with Guile
>> 2.2.2...
>> loading...     26.3% of 659 filesrandom seed for tests: 1514135440
>> compiling...    100.0% of 659 files
>> Backtrace:
>> Exception thrown while printing backtrace:
>> ERROR: In procedure private-lookup: Module named (guile) does not exist
> I successfully did `guix pull` based on that commit (b982fb1c095).
>
>> Platform:
>>
>> I am currently running guix on top of Fedora 26 x86_64. The native
>> version of
>>
>> guile is 2.0.14, and the guile used in compilation is 2.2.2 (reading from
>> the error message).
> The Guile provided by the host system is not used for `guix pull` as far
> as I can tell, so I'm not sure what's going on here.
>
> I'm curious, how did you install Guix? That is, from a Fedora package,
> our manual's instructions, etc?
Thanks for the reply. I installed Guix according to the Guix manual.
The next pull for another commit was successful. I am not sure if
this sill worth investigating.

bug#29840: guix pull failed

[Fis Trivial]

Runing `guix pull` generates the following error message:


Updating from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Building from Git commit b982fb1c09573f4638324d7809ec18d0c9956d11...
The following derivation will be built:
    /gnu/store/d8gx000cbyihr3x3gggnm9d61adjb0s3-guix-latest.drv
copying and compiling to 
'/gnu/store/42n0q7dhq5l7yd0hd550m80zw2z256fy-guix-latest' with Guile 
2.2.2...
loading...     26.3% of 659 filesrandom seed for tests: 1514135440
compiling...    100.0% of 659 files
Backtrace:
Exception thrown while printing backtrace:
ERROR: In procedure private-lookup: Module named (guile) does not exist


Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
builder for 
`/gnu/store/d8gx000cbyihr3x3gggnm9d61adjb0s3-guix-latest.drv' failed 
with exit code 1
guix pull: error: build failed: build of 
`/gnu/store/d8gx000cbyihr3x3gggnm9d61adjb0s3-guix-latest.drv' failed



Platform:

I am currently running guix on top of Fedora 26 x86_64. The native 
version of

guile is 2.0.14, and the guile used in compilation is 2.2.2 (reading from

the error message).

bug#29824: Meson 0.44.0 is broken with guix.

[Fis Trivial]

I installed meson with command `guix package -i meson`

* Error:
$ meson --version

Traceback (most recent call last):
   File 
"/gnu/store/n53zdnl4l3gm9sg15bfwxp0wdrwrvhg4-meson-0.44.0/bin/.meson-real", 
line 17, in 
     from mesonbuild import mesonmain, mesonlib
   File 
"/gnu/store/n53zdnl4l3gm9sg15bfwxp0wdrwrvhg4-meson-0.44.0/lib/python3.5/site-packages/mesonbuild/mesonmain.py",
 
line 18, in 
     from . import environment, interpreter, mesonlib
   File 
"/gnu/store/n53zdnl4l3gm9sg15bfwxp0wdrwrvhg4-meson-0.44.0/lib/python3.5/site-packages/mesonbuild/environment.py",
 
line 17, in 
     from . import coredata
   File 
"/gnu/store/n53zdnl4l3gm9sg15bfwxp0wdrwrvhg4-meson-0.44.0/lib/python3.5/site-packages/mesonbuild/coredata.py",
 
line 20, in 
     from .mesonlib import MesonException, commonpath
   File 
"/gnu/store/n53zdnl4l3gm9sg15bfwxp0wdrwrvhg4-meson-0.44.0/lib/python3.5/site-packages/mesonbuild/mesonlib.py",
 
line 60, in 
     meson_command = python_command + [detect_meson_py_location()]
   File 
"/gnu/store/n53zdnl4l3gm9sg15bfwxp0wdrwrvhg4-meson-0.44.0/lib/python3.5/site-packages/mesonbuild/mesonlib.py",
 
line 51, in detect_meson_py_location
     raise RuntimeError('Could not determine how to run Meson. Please 
file a bug with details.')
RuntimeError: Could not determine how to run Meson. Please file a bug 
with details.


I'm currently using Guix on top of Fedora 26. The installed version of 
meson is 0.44.0.


* Possible cause:
 From /mesonlib.py/: line 47~51, we have:
#+BEGIN_BLOCK python
     # The only thing remaining is to try to find the bundled executable and
     # pray distro packagers have not moved it.
     fname = os.path.join(os.path.dirname(__file__), '..', 'meson.py')
     if not os.path.exists(fname):
     raise RuntimeError('Could not determine how to run Meson. 
Please file a bug with details.')
#+END_BLOCK
which means meson will try to find the meson.py script at startup, but 
it seems Guix has renamed the this file with the new file name 
*.meson-real* and warp it with a shell script /meson/ in bin.