<mb[m]1>vagrantc: those suggestions are for variables that have been added to your Guix profile, but are unset in your environment. You probably already source "~/.guix-profile/etc/profile" in your login shell; you can either source it again, log out and in again, or set them manually. <vagrantc>mb[m]1: thanks for the explanation ... it was not immediately obvious what would happen if i didn't set them <OriansJ>its odd that guile-wm has only a single public example configuration and that single example can't even rotate between Full screen applications without a menu <xelxebar>Was just reading through the maling list about LVM support. It seems like one or two people have munged together patches but nothing has been accepted into main. <xelxebar>I'd like to migrate over to guixsd, but my disk has lvm on top of luks :/ <brendyn>Do gnus users subscribe to mailing lists and then access it via their email, or somehow download the mailing list archive directly? <xelxebar>brendyn: I have just perused it from the browser <brendyn>Hmm ok. I must be masochistic trying to learn gnus for the 10th time <xelxebar>I heavily use cli stuff. Not an emacs person myself so gnus is out of my familiarity, but I do heavily use mutt + notmuch <brendyn>I'm not any kind of person. I have all sorts of programs and my computer is messier than my bedroom :( <brendyn>Is there already a feature to create multiboot systems? I know GuixSD already creates grub entries to old profiles so this could be modified to support creating multiple independant systems with rollback support? <efraim>looks like I get to build a new guix snapshot after i finish building webkitgtk <efraim>failed in lashd before, it was probably using outdated arm assembly <rekado>lash really shouldn’t be important. <rekado>It was added to some of the core audio packages, but it is optional <efraim>debian has patches to remove the dependency <efraim>as of evaluation 109822, 8.37% build failures, either FTBFS or dependants of those <civodul>brendyn: you mean multiple GuixSD instances? <brendyn>But I guess you would still manage it as a single config, perhaps giving each "system" a name or a number, then one can reconfigure them individually, which would update the grub entries for that one system, but not touch the other ones in grub <brendyn>in that sense it's like dual-booting <efraim>i was thinking a bit about my gccgo patch set, rather than fighting to build gold it might be easier to use gccgo to build a go-bootstrap to build go <civodul>brendyn: is there really a use case for this? (honest question) <civodul>i would tend to have one main GuixSD config that i modify occasionally, and then use VMs for experimental stuff <brendyn>civodul: One might want to create a special setup for audio engineering to boot into <brendyn>With a different kernel, Jack audio kit, etc <rekado>I get the idea with different kernels, but JACK is really a per-user application. <rekado>so you wouldn’t have a system service for JACK. <rekado>I also think that the realtime kernel isn’t all that useful for general audio purposes. <brendyn>Well I'm being asked what the point of multibooting is essentially, I'm not sure what I'm supposed to say <brendyn>Some people go on stage with their laptops for live performance. having a bit-for-bit identical system to boot into and rely on is useful <brendyn>just having a userland config means the systemwide packages will change <efraim>As a short term option would it be possible to register as a GC root an os derivation and then add a custom grub menu item for that? <efraim>hash mismatch on cd-hit's source <playX>how i can enable os-prober in guixsd? <brendyn>civodul: another usage would be having a tor-only system like tails as a separate installation ***Apteryx is now known as Guest83474
<vagrantc>tails notably does a lot of UX testing and security audits ... careful about building something that just slaps tor on top <civodul>re os-prober, there's a package for that, but i think you have to run it manually <civodul>ACTION has never used os-prober, though <rekado>civodul: I’ve created a new haskell-check module and moved all test-related packages from haskell.scm there. <rekado>civodul: I also reproduced the copyright statements by looking at git log. <rekado>is it fine to make a single commit for this move? <civodul>i'm currently looking again at slot allocation, as if i couldn't stop <civodul>(not very productive so far, tho ;-)) <efraim>rekado: java-swt's 4.6 tarballs were removed upstream <vagrantc>is there anything particularly security-sensitive stored in /gnu/store? e.g. would it be safe to export read-only on a networked file system or something? <rekado>vagrantc: no secrets are stored there. <rekado>vagrantc: in fact, “guix publish” publishes your store over HTTP <vagrantc>ACTION ponders what it would take to get LTSP on guix :) <vagrantc>linux terminal server project ... a system for booting the OS over the network... increasingly deprecated thin client support <vagrantc>though it's kind of stalled for a couple years on some conceptual redesign, so probably not worth porting the "old" stuff <civodul>rekado: did you have a script for the haskell.scm split? <civodul>i'm seeing unexpected costs of the E in EDSL <davexunit>are files being split up because guile is too slow? <rekado>civodul: no script. I just cut out all packages I want and then grep the git log, then grep gnu for any references. <rekado>davexunit: just three modules: python, perl, haskell. <civodul>davexunit: because guile consumes memory roughly proportional to the number of SLOCs <rekado>davexunit: it also helps with organisation, but the primary reason for doing this right now is memory. <civodul>rekado: yeah in the end the split is probably a good thing organization-wise <davexunit>I've seen the bug reports but thought it was resolved <civodul>but doing it for that memory reason gives a bad feeling <civodul>davexunit: a sub-issue (weak tables) has been solved <civodul>on the bright side: Nixpkgs has one file per package :-) <rekado>civodul: I just feel good about distributing packages to better modules than $language :) <davexunit>yeah there's definitely an organizational benefit behind all of this <davexunit>civodul: btw I know I've been non-existent around here but I submitted a talk to libreplanet about guix, we'll see if it's accepted. <efraim>i see civodul already left, I was thinking some of the python?-pytest* packages could go into check.scm <ruuda>Hi, I am trying to write a package that requires cloning Git submodules as part of the source. How would I go about that? <bavier>ruuda: if you're using git-fetch, you can use #t in the 'recursive?' field of git-reference <ruuda>That looks like what I need, thanks! <cehteh>hum ... linux 4.14 has some bug with qemu/kvm which lets my guix VM segfault <cehteh>doesnt happen wiith other VM's yet <rekado>efraim: sounds good. Though python-check.scm would also be fine. <rekado>we also need to take care of perl.scm <davexunit>new firefox drops tomorrow with much improved performance, I wonder when an equivalent icecat release will happen. <efraim>i thought icecat mainly followed the ESR, so we wouldn't really see it until 59 <davexunit>I'm getting a little tired of that so I am exploring building firefox from source myself <davexunit>I'm attempting to build firefox 57 now and it needs rust and cargo <efraim>fun, i'll have to see about adding the aarch64 rust binary <kmicu>Alacritty, Pijul, Ion, Firefox Quantum… yesterday! <davexunit>I'm wondering how much work it would be to ship a fsdg compliant firefox that doesn't go as far as icecat does <davexunit>I think maintaining a more minimal patchset and doing less messing around would make it easier to track upstream <efraim>we also have the chromium patch that hasn't been merged yet <rekado>ACTION moves packages from perl.scm to perl-check.scm <ruuda>How can I mark an input as a build-time dependency? I have a package that contains only source code, which is compiled and linked statically in the build process of another package. If I put it in inputs or native-inputs, it is listed by guix size. <bavier>ruuda: do you list the package itself, or its source in inputs? <ruuda>The package itself. How can I list its source? <bavier>ruuda: see e.g. the "stress-make" package in gnu/packages/debug.scm:279 <ruuda>Hmm, after adding package-source it still shows up. But I also copied the source to output as a build step of that package, will try if removing that helps. <ruuda>No, it still shows up in guix size, but now with "-checkout" suffix <bavier>ruuda: so there's a reference to the that source in the package's output somewhere <ruuda>It doesn’t show up when I ldd the binary <bavier>ruuda: oh, wait, does it show up in 'guix gc --references /gnu/store/...'? <bavier>if it doesn't, probably not an issue <ruuda>Ah, so the binary does include the string to the path <ruuda>It’s nginx, and it embeds the configure line in the binary, so it an be printed when you run nginx -V <ruuda>So if it scans the binary for the string, that's a false positive <ruuda>Or perhaps I should copy the files before configure <bavier>if the source is not needed at runtime, we probably want to avoid retaining the reference ***cstrahan_ is now known as cstrahan
<ruuda>Copying the source files before the configure step did the trick! Thanks a lot for your help bavier ***erdic_ is now known as erdic
<ruuda>I now have an Nginx package with ngx_brotli module enabled, would anybody be interested in that? <civodul>rekado_: how did you handle copyright lines for haskell*.scm? <civodul>i'm checking manually but it's tedious <rekado_>I did “git log | grep -E -B5 "gnu: (Add )?(a|b|c|d|e|f…)"” <civodul>rekado_: ok, i do: git shortlog --format='%aN %aE %aI %s' |grep PKG <mb[m]1>ruuda: In some cases we also edit packages to not record build flags for that reason, there is an example in the "php" package. <mb[m]1>Was someone working on fastboot for Guix? I'm half-way through, but the rabbit hole is pretty deep. <ngz>I'm trying to track down Scribus' bug (which cannot start properly outside a --pure environment). It tries to use system's Python instead of the one provided as an input. Setting PYTHONPATH does not change anything. Would setting PYTHON_INCLUDE_PATH and PYTHON_LIBRARIES instead help? <ngz>or does cmake-build-system take care of it, somehow? <bavier>ngz: setting PATH would probably help <bavier>cmake-build-system doesn't do that <ngz>wrapping PATH around the executable? If so, to what value? <bavier>though maybe a patch to the source would be better, to avoid a wrapper <ngz>Unfortunately, I do not know where this happens. One Scribus developer told me it didn't call the python's executable itself. Scribus uses libpython. <ngz>I don't know. How can I be sure? <ng0>with regards to rust: how much of the last status update on the build-system completion has been ticked off, if anything of it? <bavier>ngz: you could start up scribus under strace <bavier>and look for libpython in the output <ng0>I'd like to get my 100 rust crates in the branch working (and some more, but 100 are essential), sadly I'm doing many others things already and can't help.. topic for next GsoC maybe? or is this too little for a students assignment for someone? <ngz>bavier: I already have that output in front of me. <ngz>I get : open("/gnu/store/snk1lslg3ykmxmf2qjf13x59d6krpkv1-python-2.7.13/lib/libpython2.7.so.1.0", O_RDONLY|O_CLOEXEC) = 4 <ng0>that is, fixing the rust build-system, not fixing my crates (that is implicit ;)) <bavier>ngz: is libpython in `ldd scribus`? <ngz>`ldd scribus` returns "ldd" <bavier>ngz: hmm, so scribus can't load that library unless under 'guix environment'? <ngz>AFAIU, it can always load that library. However, in guix environment, it cannot do stat("/usr/bin/python", {st_mode=S_IFREG|0755, st_size=3783608, ...}) = 0 <ngz>and, e.g., stat("/usr/lib/python2.7/os.py", {st_mode=S_IFREG|0644, st_size=25910, ...}) = 0 <mb[m]1>ngz: Can you find the '/usr/bin/python' string in the source code? <ngz>No, there is no such thing. Besides, /usr/bin/python is a fallback value, it first look for: stat("/home/ngz/.guix-profile/bin/python", 0x7ffe72a69540) = -1 ENOENT (No such file or directory) <ngz>So it probably looks for "python", whatever that means. <mb[m]1>Oh, so it already searches PATH. <taohansen>is gpg-agent only included in gpg2+ or is gpg-agent spun off into its own package? <mb[m]1>A "quick fix" would be to simply wrap it with python in PATH. I did the same for "weechat", as it was too much work to make it pick it up at configure time. <ng0>davexunit: I think it was you mentioning earlier work on newer FF. I seem to remember working on this some months ago. Not sure where I left it (at which build process failure) <ngz>I see. I thought wrapping PYTHONPATH would do it, but it does not. I can try to wrap PATH instead.