<mark_weaver>sneek: later tell jmd: creation of an installer is blocked on getting 'guix system vm' working on mips64el, which is blocked on getting qemu to work on mips64el. we may also need a different kernel config for whatever mips machine qemu emulates.
<ng0>I will go through my work in progress folders in the next days/weeks to rebase what I have there and let interested people pick those applications (like I did with awesome-3.5.9) so I can focus on packaging for gnunet & psyc* related things fulltime again
<ng0>for the pbpst related patches, I had a chat with the dev yesterday and will apply the latest fixes, see how it behvaes now and send out rebased patches.
<rekado_>ng0: cool! I'll take a look at them some time this week.
<rekado_>ng0: do you have a list of all your patches that still need review?
<rekado_>I haven't been able to process much of Guix-related emails in the past weeks.
<ng0>I can go through my tags and send a list including gnu.org links and/or subjects, not today but later
<rekado_>ng0: thanks. Please just send it to me at your convenience. I'll take some time to review them.
<ng0>one set I know: the 13 perl patches before surfraw can be applied is bavier reviewing, those are time consuming I guess and I have patience :)
<rekado_>one problem of my email setup is that I'm sending and receiving guix-devel and bug-guix email on two accounts. mu4e does a poor job of merging and displaying threads, so I get all mail twice and it appears out of order when I view them.
<rekado_>need to add a rule to just bin all guix-devel mail on my work mailbox, unless I'm in Cc.
<rekado_>does anyone here have a software recommendation for sync'ing *and* filtering email? I'm using offlineimap for sync but I'd really like to run a couple of filters locally upon sync to automatically move mail around or tag it (e.g. when my name is mentioned).
<ng0>what, if at all, can I suggest to the developer to make abuild phase "make simple" they created to allow systems like Guix and Nix to patch the make.sh, which is created during this make phase, before it is executed?
<ng0>otherwise I know how to override it already, but I'd like to fix it
<ng0>could it be better to have the generation part in one phase, and the execution of make.sh in a phase afterwards, so that nix and guix can hook in between those phases?
<malthe>anyone created a guixsd image on google compute engine?
<ng0>I mean this is guile, there has to be something which could enable instructions to interactively patch the file... if file is detected, run patch-shebang,...
<ng0>could also suggest to move @./make.sh to a second phase.. easier.
<retroj>hi, i'm having some trouble with tests with the ola package. http://retroj.net/scratch/ola-guix/ contains ola.scm (package definition), config.log, and test-suite.log, which indicates a missing python module, google.protobuf. any thoughts?
<retroj>config.log shows that ./configure checked for the existence of the python module
<steveeJ>is GuixSD using a fork of hydra or is the original compatible with guix?
<ng0>so now rust on guix is something I need to succeed with one part of the projects I focus on primarily... what the status update on this?
<rekado_>steveeJ: GuixSD downloads substitutes from hydra or from a server started with "guix publish". The protocol has not changed as far as I know.
<rekado_>steveeJ: we are in the process of replacing hydra with cuirass.
<rekado_>steveeJ: you cannot use the Nix hydra servers with Guix because they don't provide matching binary substitutes for Guix package builds.
<steveeJ>rekado_: I'm looking at using either nix or guix for a project and it includes having a build-farm
<steveeJ>rekado_: I see, so it is really either or and I couldn't feed one hydra with guix and nix at the same time
<rekado_>I don't have any experience running hydra myself, so I don't know what's involved.
<rekado_>I just know that there's no overlap in the software dependency graphs of Nix and Guix, because even the bootstrap binaries differ, so substitutes for Nix will differ from substitutes used with Guix.
<davexunit>so we could package rust similarly, I suspect, and add it to the list of compilers that we need to bootstrap properly in the future
<ng0>I'm interested in it because I want to stay ahead of releasing, and include a guix.scm for a project before it gets to release state.. prototype2016 moved to a rust build system.. easy for nix, currently impossible for guix
<sankey>how can i determine the reason a path in the store is still "alive"
<sankey>when i follow its --referrers to a profile, that profile is not referenced from any user
<sankey>i even checked under /var/guix/profiles/per-user/ and there's no symlink which points to that profile
<sankey>maybe an open file descriptor to the profile can cause this?
<retroj2>the problem i'm having with the ola package (see logs here: http://retroj.net/scratch/ola-guix/ ), i would guess, has to do with PYTHONPATH. the package depends on python-protobuf, which does provide the module google.protobuf, but then python tests during check phase fail to find the module. is there something else that the package needs to do to make python modules available in its build environment?
<alezost>retroj2: try to grep for PYTHONPATH in the "gnu/packages/*.scm", perhaps you'll find something
<lfam>bavier: How can I check if ImageMagick is built to support SSE2?
<lfam>Change of subject: the next release of Git (2.10.0) will no longer display the short PGP key id
<lfam>I'm not sure if it's the long ID or the fingerprint, but some improvement :)
<davexunit>bummer, gnome isn't recognizing the external monitor I plugged into my laptop :(
<lfam>sankey: I think the problem is that the egg gets compressed, so the Guix reference scanner can't look into the binary and find store references. Can you try this patch? http://paste.lisp.org/+6Y0W
<lfam>With that patch, `guix gc --references $(./pre-inst-env guix build python-magic)` shows the reference to the file package, so it should be protected against garbage collection
<sankey>lfam: thanks for looking into it! i will try later
<lfam>sankey: Okay, I'm going to go ahead and push the patch. It appears to solve the issue on my end
<bavier1>lfam: for sse2 in imagemagick, it might need the -msse2 compiler flag
<retroj2>ola provides a C++ library, a daemon, some utils, and some bindings for various other programming languages. thinking about the extra bindings, would a good way to set that up be to provide them as separate outputs of the package?
<bavier1>retroj2: I would consider it if it would trim down the closure size of a typical installation
<retroj2>i just don't want a dependency to pull in python or java if the person doesn't want that
<bavier1>retroj2: right, that'd be a perfect candidate for separate outputs
<bavier1>so, with the last llvm upgrade we did, we were wondering how many versions of llvm it makes sense to keep around. I was thinking about packaging a cool project, one that's linked on llvm.org even, and it requires llvm 3.4
<jmd>I can't think why it should be particularly disk intensive.
<bavier1>jmd: the union-build procedure has to scan through files in the store and symlink them all into the profile
<bavier1>its very expensive on my spinning disk with failing sectors, but completes in almost not time on my machine with SSD
<retroj2>when a package has multiple outs like i described, when more than one is installed, does each have its own directory in the store, or do they share a single build? when one depends on the other (like python bindings depending on the c++ library), does that involve multiple copies of the library being built?
<bavier1>retroj2: the outputs will be produced in a single build, but they'll be installed to separate store directories
<jmd>bavier1: Why does it have to scan? I thought the idea of the database was that it knows where to look.
<bavier1>jmd: the database doesn't know about all files in a store dir
<jmd>well it knows the package directories, doesn't it?
<mark_weaver>lfam, bavier1: I don't have time to read the whole log, but I saw mention of imagemagick and SSE. On i686, we shouldn't assume support for SSE. On x86_64, SSE2 is part of the base specification (always present), and GCC should know this without being told.
<mark_weaver>in fact, this is why double-rounding doesn't occur on x86_64, because SSE/SSE2 instructions and registers are always used for even scalar floating point operations, and the use of the registers is part of the ABI.
<bavier1>mark_weaver: oh good, thanks for clarifying
<bavier1>I should really be able to keep such things straight
<mark_weaver>no need to feel bad about it, I'm sure you have plenty of useful knowledge that I lack :)
<davexunit>I've been thinking a lot about making 'guix environment' a more "first-class" thing, with a data structure for describing environments, much like you'd describe a package or operating system
<davexunit>I'd like to make containers an optional feature, rather than mandatory, for its use, though.
<davexunit>my current thinking is that the user can specify the packages they want in their environment as well as shepherd services that will be started by a shepherd instance running under their user account.
<davexunit>this way, in a single command you could create a development environment that, for example, spawned mysql, nginx, and redis daemons that are needed for a web application to work
<davexunit>this is even better than putting every single dependency in its own container