IRC channel logs


back to list of logs

<pkill9>does guix's gstreamer have mp3 support?
<pkill9>oh nevermind, i didn't realise the other gstreamer plugins were named gst-plugins-*
<pkill9>hmm, it seems even after adding all the gst-plugins, rhythmbox fails to read mp3 file with Rhythmbox-Message: 00:03:43.794: Missing plugin: gstreamer|1.0|rhythmbox-metadata|MPEG-1 Layer 3 (MP3) decoder|decoder-audio/mpeg, mpegversion=(int)1, mpegaudioversion=(int)1, layer=(int)3
<pkill9>ah, it's fixed, it needed gst-libav
<reepca-laptop>sneek: later tell kkebreau: seems that if we're using pulseaudio (which %desktop-services does) we should have ALSA_PLUGIN_DIR set to ~/.guix-profile/lib/alsa-lib and have alsa-plugins:pulseaudio installed in our profiles. After doing that, audacity works, but alsamixer doesn't - it fails with "munmap_chunk(): invalid pointer"
***jonsger1 is now known as jonsger
<apteryx`>guix import cpan Getopt::Std --> In procedure hash-map->list: Wrong type argument in position 2 (expecting hash-table): #f Am I doing this wrong??
<apteryx`>oh, it's included in the core. It's probably not listed.
<vagrantcish>"guix environment --container guix" ... "./configure --localstatedir=/var/guix" or just /var, or /var/, or /var/guix/ ? followed by "make" and then "make check" ?
<vagrantcish>that should set up a pre-inst-env that works?
<vagrantcish>looks like configure --localstatedir=/var ... according to
<brendyn>Guix pull failed: In procedure private lookup: No variable bound to define-module* in module (guile)
<brendyn>Ok I think it was because my locales werent set right
<brendyn>rekado_: I could not find the manual page you mentioned about making guix packages see system fonts
<axd[m]>I've been having a problem lately with my laptop not waking up from suspend properly. I'm still trying to narrow this down, but the main symptoms are that if I close my laptop's lid AND a few hours pass, I then go to open the lid I find the screen blank completely. However if I press ALT+CTL+{1-6}, then the laptop switches to a different virtual console without a problem. If I then switch back to virtual terminal 7 then I see
<axd[m]>the X server (I think) output a bunch of stuff and throw me in from of SLiM as if I logged out. I'm still trying to figure this out, maybe my laptop tries to hibernate after some time, but I'm not sure what governs that. Is it elogind? Where are its settings to see if it tries to hybernate at all? I'm using EXWM with Emacs, don't know if it's related to the WM. If I suspend and wait a normal amount of time, then the symptoms
<axd[m]>don't occur. No idea how to start debugging this.
<vagrantcish>have similar symptoms sometimes, though i didn't know the workarounds...
<axd[m]>vagrantcish: what DE/WM do you use? Do you use GuixSD or a laptop or desktop?
<axd[m]>vagrantcish: and you have similar symptoms where upon waking from suspend you just get a blank screen? Are you also able, like me, to switch to a different virtual console?
<axd[m]>sorry I just reread what you originally wrote. So you would forcefully restart every time? How often does that happen with you?
<axd[m]>vagrantcish: one thing I have found people do is that before suspending they switch to a different virtual console and then upon waking, go back to the graphical one. Someone just wrote a hook as a script and did this. This was a workaround in Ubuntu 13.04 though.
<vagrantcish>axd[m]: yeah, i've had to just hold to power-button ... but maybe the tty switching would work.
<axd[m]>at least I'm not the only one experiencing this. Have you set up hibernation and/or swap space?
<vagrantcish>not intentionally ... i am using tlp, though.
<axd[m]>vagrantcish: I'm using tlp too. How often does this happen to your laptop?
<vagrantc>axd[m]: haven't quite figured out a pattern
<vagrantc>axd[m]: it used to happen more often until configuring tlp to disable usb autosuspend
<vagrantcish>axd[m]: i've got in my config.scm: (service tlp-service-type (tlp-configuration (usb-autosuspend? #f)))
<axd[m]>interesting, I'm gonna monitor my patterns more as well. I wonder if anyone with a DE gets anything like that or is it that WMs happen to not manage something.
<axd[m]>yeah I have the exact same thing for tlp, honestly don't remember if it happened more or less or at all before I added that.
<axd[m]>I just know that my external keyboard and mouse aren't usable with usb suspend so it's required to be off. Tlp's options to whitelist just specific USB ID also didn't work for me, so I had to resort to turning off all usb-autosuspend like yourself.
<brendyn>guix pull is now hanging using 100% of my cpu while compiling. hmmm
<civodul>Hello Guix!
<janneke>hi civodul!
<reepca-laptop>Out of curiosity, why doesn't the alsa service show up when I run herd status? It's neither in started nor stopped, but it's in %desktop-services (I was really puzzled at what had started pulseaudio)
<reepca-laptop>... and now I just realized that my trailing question mark should have been a trailing period. ¯\\_(ツ)_/¯
<ngz>Is there a way to match more than one line with substitute* command?
<efraim>I assume you mean a multi-line substitution, not reallu
<efraim>All the lines that match will be substituted though
<ngz>I'd like to remove a whole <li>...</li> in an HTML file.
<ngz>Unfortunately it spans over multiple lines.
<efraim>Sounds like you need a patch
<civodul>reepca-laptop: the ALSA service is not a Shepherd service
<civodul>ngz: perhaps you should use xml->sxml and all that
<ngz>civodul: so, it sounds like I need a patch, right? ;)
<civodul>ngz: a patch for what? not sure i follow
<civodul>all i'm saying is that you might be better off parsing the whole HTML than doing string substitutions
<ngz>I need to prune an item from a HTML file. Parsing the HTML document, removing the item from the Sexp, and turning the result back into HTML sounds like overkill.
<civodul>not that overkill if you ask me :-)
<civodul>it's the only reliable way to do it, and it's not much code
<reepca-laptop>ngz: it really depends on how much you expect the structure of the document to change.
<ngz>civodul: Are there examples around about how to do it?
<ngz>reepca-laptop: Not much. That's a single <li> in a <ul>.
<civodul>ngz: first step would be: (call-with-input-file "thing.html" xml->sxml)
<civodul>and then you can use sxml-match, or match, or your own XML walking code
<ngz>I see how you match the offending <li>, but how do you remove it?
<rekado_>the “netsurf” package does something like that.
<rekado_>also “axoloti-patcher”
<rekado_>and “java-forester-1.005”
<efraim>ecj-java-wrapper is killing me
<efraim>i think it may be the double back-ticks
<civodul>double back-ticks are evil
***psachin` is now known as psachin
<rekado_>but they are 20 lines apart :)
<rekado_>in ecj-java-wrapper we write a quoted Guile script to a file, but this happens in a builder, which is part of the quoted arguments of the package.
<efraim>i'm inside (apply system* ,java , changing the arguments for armhf
<efraim>.... and it seems all of that was for nothing, while testing both cases of if i got a successful package
<efraim>now on to classpath-jamvm-wrappers
<ngz>rekado_: Thank you for the pointers. However `pre-post-order' documentation is killing me.
<efraim>and I found my CD-Rs! I can finally burn an install CD for my PPC G4 mac
<efraim>now on to classpath-jamvm-wrappers for real this time
<civodul>"FS-Cache: Duplicate cookie detected"
<civodul>"FS-Cache: O-cookie c=00000000a5db33c0 [p=000000000e531435 fl=226 nc=0 na=1]"
<civodul>looks like the kernel devs left some new debugging statements
<snape>is there a way to refer to a local git repository with the 'git-fetch' method?
<snape>hmm nevermind, I've found a way around
<nee`>For some reason `guix system` gives me 'guix: system: command not found'. The version is a87cb7a73bc4f9df614ffdb2ce2c51aa04c379e5 Is there any workaround? guix pull still works, so can I somehow run the guix in .config/guix/latest? I'll fetch the git repository otherwise.
<brendyn>nee`: ive seen other people talk about having that issue. check the mailing list or search the irc logs on the gnunet site and maybe you'll find the answer
<rekado_>nee`: there is no more .config/guix/latest; a full Guix is installed to .config/guix/current upon “guix pull”.
<rekado_>use .config/guix/current/bin/guix instead.
<jlicht>hey guix
<sdb>hey guix :)
<sdb>I miss the "clear" command in terminal. Which package provides this?
<jlicht>sdb: for me, ncurses does
<jlicht>but C^l should also work I think
<sdb>jlicht, thanks. C^l worked!
<nee`>rekado_: that doesn't exist for me. It seems I still have an older version. I thought the pull I did yesterday did pass though. I'm trying to build from the git repo now.
<sdb>nee`, how many times did you pull?
<rekado_>nee`: you shouldn’t ever need to build from the git repo.
<sdb>nee`, did you search the store for guix?
<rekado_>there’s no need to search the store
<rekado_>nee`: you may just need to run “guix pull” again.
<sdb>nee`, did you pull as another user? If so that user should have .config/guix/current populated if the pull succeded..
<nee`>I only pulled only once, but I didn't update in a few weeks. I guess a lot of stuff was changed. The sources from git seem to be building in `guix environment guix --ad-hoc guile-sqlite3` so that will probably solve it for me.
<sdb>nee`, if you pull again you can save time by pulling one of the commits hydra already built see
<sdb>nee`, i'm on 8edebd3 and it was a breeze to pull when hydra already did the compiling :D
<nee`>Nice to see that guix pull finally gets a speed up
<jlicht>hmm, now I do not have the time to get a nice cup of coffee anymore anytime I run `guix pull' :'(
<sdb>jlicht, what a pitty. And your processor does not get to work that hard either.
<jlicht>exactly! My office will be so cold come winter ;-)
<sdb>jlicht, you might have to join SETI@home to keep warm ;-)
<pkill9>just need a script to find out the latest guix git commit that has been built by hydra/berlin
<civodul>if you get binaries from, 'guix pull' usually has substitutes for at least a subset of the derivations
<civodul>so if you're lucky it takes less than 5 minutes, which i admit is still way too much, but an improvement
<civodul>emms uses ogg123 to play FLAC files, but ogg123 produces no sound with FLAC (it works fine with Vorbis)
<snape>I can't access berlin's Cuirass API. Is it down?
<civodul>ACTION tries
<pkill9>snape: where is it's api documented? I want to make a script but can't remember where the api is documented
<snape>pkill9: in Cuirass documentation
<civodul>snape: Cuirass is definitely up and running but its web server doesn't seem to respond
<snape>pkill9: it should look like this:
<pkill9>ah thx
<snape>but it doesn't work ATM
<civodul>it seems to be a fiber/scheduling issue in Cuirass
<civodul>2018-06-26T14:01:57 builds request took 309.280045 seconds
<snape>civodul: so I guess there is a fiber blocking operation somewhere, that hasn't been caught
<snape>like 'git clone'
<snape>civodul: it would be great to know from which fiber a log message comes
<civodul>snape: re logging, i agree
<civodul>it's sometimes confusing
<roptat>civodul: with guix-modular I can now run guix pull on my server \\o/
<civodul>roptat: is that on arm?
<roptat>no, x86_64
<roptat>but it's running on 512MB of RAM
<civodul>i see
<civodul>you could already get substitutes from though :-)
<roptat>well, it didn't work so well, because I have no idea how to get a commit number that berlin built
<roptat>hey that's funny because I got the substitutes from berlin ^^'
<snape>roptat: see upper history, the API link
<civodul>also, you can always hope that it did build most of it
<snape>civodul: there's a small bug in 'maintenance'. Where can I send a patch?
<snape>(it's (#:no-compile? . #t) instead of (#:no-compile? #t))
<snape>it works because of luck right now :-)
<snape>*by chance
<civodul>snape: you can cmomit the fix directly
<civodul>it's in the services module, right?
<civodul>snape: so yes, go ahead with the fix :-)
<ngz>Python newbie question. I use the trivial build system to install a Python package that consists of a bunch of ".py" files (but no Unfortunately, when executing the Python script, it cannot load modules provided as inputs in the package.
<ngz>I though about wrapping the executable with a PYTHONPATH definition, but `getenv "PYTHONPATH"' returns #f.
<ngz>So, how can I tell the Python script how to find its inputs?
<mbakke>ngz: We normally propagate Python inputs (except for non-library executables), which will setup PYTHONPATH at installation time.
<ngz>Propagating inputs doesn't change anything here.
<mbakke>If this is not meant to be used as a library, you should instead iterate over the inputs and wrap it with PYTHONPATH "manually".
<ngz>Besides, are you sure trivial build system takes care of PYTHONPATH?
<mbakke>ngz: You also need python in the profile for PYTHONPATH to be created.
<ngz>"python" is a native input.
<ngz>mbakke: for reference, here is the package:
<ngz>the wrap-program part doesn't work, for the reason explained above.
<mbakke>For trivial-build-system, if you want the variable set at build time, you'll need to extract the relevant parts of (@@ (guix build gnu-build-system) set-paths*).
<mbakke>ngz: trivial-build-system will not set up any environment variables for you. So you'll need to iterate the inputs and create PYTHONPATH in the builder.
<snape>yeah, usually, working with the trivial build system isn't trivial :-)
<mbakke>Heheh. Perhaps it should be renamed to 'difficult-build-system' :P
<ngz>So I guess something like (string-append (assoc-ref outputs "out") "/lib/python3.6/site-packages") doesn't cut it as PYTHONPATH. I need to append every "/lib" directory from the inputs.
<efraim>It might be easier to use the python-build—system and remove extra bits
<thekyriarchy>axd: hey, i was already in here!
<Copenhagen_Bram>so why is scheme the only language available for laby?
<bavier>Copenhagen_Bram: I think laby looks for the needed compilers at runtime, so you'll have to install/provide those if you want them available in laby
<bavier>guile/scheme is always available on guixsd ;)
<civodul>just stumbled upon this paper:
<civodul>commented in
<g_bor>Hello guix!
<sneek>Welcome back g_bor, you have 1 message.
<sneek>g_bor, reepca-laptop says: seems that if we're using pulseaudio (which %desktop-services does) we should have ALSA_PLUGIN_DIR set to ~/.guix-profile/lib/alsa-lib and have alsa-plugins:pulseaudio installed in our profiles. After doing that, audacity works, but alsamixer doesn't - it fails with "munmap_chunk(): invalid pointer"
<g_bor>sneek: botsnack!
<bavier>civodul: very cool
<bavier>civodul: do we have patches for the "fixed" packages mentioned?
<g_bor>I'm looking for a feature in guix graph. It would be very useful for bootstrapping. I'm looking for the intersection of a graph of a package, with the the reverse graph of another. What would be the easiest way to do this?
<lfam>g_bor: I don't have a ready-made solution for you, but `guix graph` speaks Graphviz's dot format, so it should be possible
<civodul>bavier: yes, there are links in the references :-)
<pkill9>what are the unreproducible packagesfrom Guix that the intro of that paper refers to?
<bavier>civodul: thanks, skimmed over that I guess.
<pkill9>oh i found them in the paper
<bavier>pkill9: djvulibre, libjpeg-turbo, and skalibs
<pkill9>yeah :)
<g_bor>lfam: I tried to find out why openssh does not start on boot, but any messages are scrolled off from tty1, so no idea.
<lfam>g_bor: Yeah, I'm still working around it :/ My day job has finally slowed down so I'll have more time to debug it this summer
<civodul>lfam: it'd be good to get to the bottom of this, i really don't understand what's going on
<lfam>"This summer" starting now ;)
<civodul>heheh :-)
<civodul>there's even code here:
<civodul>looks like Perl tho :-)
<civodul>actually there's no code there, hmm
<lfam>That makes it very easy to reproduce
<civodul>yeah :-(
<lfam>Any git-annex users, see this urgent security advisory:
<lfam>The Guix package update will be pushed shortly
<lfam>And... pushed. The fixed tarball was not provided in advance so I haven't finished building this particular code, but all the release candidates built okay.
<civodul>lfam: ouch, that sounded pretty bad
<civodul>thanks for the super-fast fix!
<civodul>i understand why joeyh came on this channel recently :-)
<lfam>civodul: joeyh made the effort to include us in the coordinated disclosure
<lfam>Yes :)
<civodul>that was by private email?
<civodul>i think our "security" page does not include encryption information
<lfam>Yes, I saw his messages in the IRC log and contacted him directly
<lfam>I let him know that he could either use <> or directly communicate, using PGP, with either me or the Guix maintainers
<civodul>perhaps we could list individual keys on the web page?
<lfam>Yes, this experience shows that some reporters will only send pre-disclosure bugs with encrypted mail
<civodul>makes sense
<civodul>would you like to update that web page with the list of keys?
<lfam>Sure. For you, me, and rekado?
<civodul>i can sync the HTML afterwards, if you want
<civodul>yes, and maybe Mark
<lfam>Okay, good idea
<rekado_>thanks for handling this!
<civodul>yup, really nice
<civodul>roptat: thumbs up: the translation of dates in "guix pull -l" is *much* nicer than what Coreutils' 'date' program does
<civodul> <- interesting links there
<Copenhagen_Bram>How do I install tor on guixSD?
<vagrantc>installing it is easy, haven't managed to figure out how to configure it :)
<nckx>Copenhagen_Bram: Add tor-service to your services. I use (tor-service (local-file "torrc.nckx")) to avoid the Scheme abstraction.
<Copenhagen_Bram>i had to use the power off button because prboom-plus crashed on fullscreen, now the guix manual is in french. What do I do?
<ngz>Learn french? ;)
<Copenhagen_Bram>but duolingo is proprietary
<Copenhagen_Bram>*accidentally middle clicks terminal tab running guix pull, closing the tab*
<Copenhagen_Bram>i guess i'm playing it risky today
<efraim>run it in screen
<janneke>ACTION just released mes 0.16
<Copenhagen_Bram>ngz: srsly
<Copenhagen_Bram>i just found out there's an info main menu, and there were some options for english guix pages. I tried opening one and got "Cannot find node 'Invoking guix build'"
<ngz>I think both manuals are created
<Copenhagen_Bram>created by what? maybe I can update guix or something
<Copenhagen_Bram>i am running guix pull, so maybe that'll fix it?
<ngz>I mean, if you use Emacs, every node appears twice
<ngz>One node is in french, the other in english.
<ngz>No, running guix pull will not fix it.
<ngz>Texinfo is not nice with localization, that's all.
<Copenhagen_Bram>the manpage for youtube-dl is rather lengthy and repeating ._.
<Copenhagen_Bram>is that related?
<Copenhagen_Bram>also why don't i have a locale command?
<Copenhagen_Bram>hey snape
<snape>hey Copenhagen_Bram
<Copenhagen_Bram>do you know anything about why my guix manual is no longer available in english?
<snape>no, but surely roptat does ;-)
<Copenhagen_Bram>ngz recommends that i learn french but duolingo is proprietary so i'm not sure how to do that nowadays
<snape>It's a good idea. There might be other ressources.
<snape>is your locale English?
<snape>(the output of the 'locale' command)
<Copenhagen_Bram>the output of the locale command is command not found
<snape>Copenhagen_Bram: did you specify the 'locale' of your 'operating-system'?
<snape>in your config.scm
<Copenhagen_Bram>no, how do I do that?
<snape>in your config.scm: (operating-system ... (locale "en_US.UTF-8") ...)
<nckx>Copenhagen_Bram: If you meant ‘lengthy and repeating’ literally: that's a known bug. <>
<snape>(locale command is provided by 'gcc-toolchain')
<nckx>snape: Possibly, but not primarily. It's provided by glibc.
<nckx>gcc-toolchain might pull it in too.
<snape>yeah, I just did 'which' :-)
<ngz>You have glibc in your profile?
<snape>but you're right, gcc-toolchain is clearly overkill
<nckx>ngz: I do.
<nckx>Nice things like ‘ldd’ live there.
<ngz>I mean: I thought gcc-toolchain was more common than glibc in profiles.
<snape>ldd is in gcc-toolchain too
<nckx>ngz: OK, but that's far more than I want or need.
<nckx>I assume everything in glibc/bin is in gcc-toolchain by definition (I've always seen it as a ‘union’ wrapper), but then so is, well, gcc :-p
<snape>yeah the question is rather: how can you live without gcc-toolchain :)
<nckx>The obviously one and true answer: package everything for Guix!
<nckx>(Until you encounter a rust package of course, then you just give up and cry.)
<lfam>sneek: later tell civodul: I pushed the security reporting changes we discussed to guix-artwork.git. Can you deploy the changes?
<Copenhagen_Bram>ACTION pokes roptat
<Copenhagen_Bram>snape said you could help me with texinfo language issues
<Copenhagen_Bram>if i don't fix this i'll be doomed to view the guix manual in my browser forever
<roptat>Copenhagen_Bram: hey, I look at the manual through my browser :)
<roptat>not sure what the issue is, can you explain (or point to the log)
<roptat>ah so I didn't fix *all* the node links in the French manual
<roptat>Copenhagen_Bram: "info guix" should give you the English manual
<roptat>while "info" should give you the French manual
<g_bor[m]>roptat: How hard do you think it would be to unbundle maven-plugin-api from java-jarjar? Seems like a tough one.
<Copenhagen_Bram>roptat: but 'info guix' gives me the french manual
<Copenhagen_Bram>that's basically the issue. How do I look at the log?
<Copenhagen_Bram>lemme try looking that up first
<pkill9>i don't like manpages or info pages
<roptat>g_bor[m]: isn't there a loop?
<roptat>Copenhagen_Bram: that shouldn't happen
<roptat>oh it does for me too
<roptat>I have no idea how info works though
<roptat>LANG doesn't seem to change anything
<roptat>so what you can do for now is "info", then go down to "Guix (guix)" (not "Guix (")
<roptat>but I don't know why we get the French manual
<civodul>roptat: the info-dir profile hook adds both manual to 'dir'
<civodul>so i think we should arrange to generate 'dir' *and* 'dir.LANG'
<civodul>for 'dir.LANG' to be automatically selected, we'll have to fix the Info readers, but we can do that later
<civodul>oh wait, you're saying "info guix" opens '', right?
<civodul>i see that too
<Copenhagen_Bram>roptat: i tried that, it says cannot find node
<Copenhagen_Bram>you too, huh?
<pkill9>what does it mean when i get this error during building a python package: error: option --single-version-externally-managed not recognized
<civodul>Copenhagen_Bram: "info '(guix)'" gives you the English one
<ngz>pkill9: You have to tell python build system to not use setuptools
<ngz>i.e. #:use-setuptools? #f
<pkill9>ah ok
<g_bor[m]>roptat: What I did with java-asm was to make a bootstrap version of all packages, without the tests, and that broke the loop. As the only rdeps of jarjar are the hamcrest packages I guess that could also work out here, but it seems that there are a lot of packages involved.
<roptat>Copenhagen_Bram: no, I do get the english manual
<roptat>as ludo said, "info '(guix)'" opens the English manual
<pkill9>which is better when replacing the python check phase: (zero? (system ...)) or (invoke ...)
<nckx>pkill9: invoke.
<pkill9>why is that out of interest?
<jonsger>civodul: how can I run the "basic.test" from guile-sqlite3? because "guile basic.test" throws "no code for module (sqlite3)"
<ngz>Speaking of the manual, I think @node Power management Services is missing @subsubheading TLP daemon and @subsubheading Thermald daemon. WDYT?
<nckx>pkill9: INVOKE throws an exception if an error occurs, aborting the build. SYSTEM[*] returns the exit status instead, which is just ignored in practice.
<civodul>jonsger: using 'make check'
<ngz>Also, it should be "Power Management Services", not "Po"
<nckx>pkill9: The frequent use (zero? (system...)) is an attempt to return #f if an error occurs, but it turned out the build doesn't actually do anything with that so it's a bit misguided :-)
<ngz>err not "Power management Services"
<pkill9>ah i see
<ngz>Let's fix this.
<jonsger>civodul: throws file: "libsqlite3", message: "file not found", I did it in "guix environment guile-sqlite3"...
<sdb>hi guix :)
<civodul>jonsger: oh right, you need to set LD_LIBRARY_PATH to point to's directory
<civodul>it's pretty bad
<civodul>the new maintainer should fix it :-)
<jonsger>civodul: I prepared a README file. I'll include this :P
<civodul>jonsger: i'm happy to apply it upstream
<civodul>or better yet, you could get in touch with Danny
<civodul>and explain they were elected new maintainer ;-)
<jonsger>is he in IRC?
<demotri>Why is guix build --no-substitutes doing totally different things than without that parameter? Example: 'guix build -S aseba' ist just downloading the sources from substitute servers. 'guix build -S --no-substitutes aseba' is downloading sources for libtiff first!
<sdb>i'm playing with guix environment and building from git tonight
<ngz>I feel much better now.
<jonsger>civodul: on opensuse I don't need to set this path...
<sdb>After cloning and running guix environment I cannot execute the ./configure script. error: file not found.
<sdb>I just peeked into and saw a comment about running "autoconf". Just did that.
<demotri>sdb: ./bootstrap is your first step
<sdb>Voila' a configure-script!
<sdb>I'm following the manual but it seems to be missing some steps
<snape>sdb: it says "Run ‘./bootstrap’ to generate the build system infrastructure using Autoconf and Automake."
<demotri>I think the problem is that most commands are set up in a text box (i.e. code element). But the part with "./bootstrap" is in a text part. So if you quickly scan over the text, you might loose that command.
<civodul>jonsger: i don't think Danny is on IRC
<snape>demotri: yes, right
<jonsger>civodul: is there a simple way to test that the guix depending on guile-sqlite3 works properly. So like a command which should file when there is something wrong with guile-sqlite3?
<civodul>jonsger: 'make check' in Guix
<civodul>jonsger: specifically, 'make check TESTS=tests/store-database.scm'
<sdb>I will propose changes to the manual that makes it easier for non-programmers to compile guix. Usually when I compile stuff it usually comes with a configure-script.
<civodul>sdb: the tarball comes with a configure script, but here you're building from a checkout
<civodul>it's naturally a bit more involved
<sdb>A ha I missed the .bootstrap instruction in "building from git" it seems.
<sdb>civodul, ok, understood. Thin ice for a learning not yet programmer :)
<demotri>sdb: Patches for the manual are welcome :-)
<pkill9>is there a way to run unit tests in the guix build process that require a display?
<sdb>on a running guixsd I want --localstatedir=/var correct?
<snape>pkill9: yes, see the 'gajim' package
<demotri>sdb: yes.
<pkill9>cool thanks, didn't think it was possible
<sdb>it is not clear from the manual whether I should run "make test" before running "make"
<jonsger>civodul: oke, thanks. I'm usually more interested in something running from an installed guix. To see if it installed correctly...
<snape>sdb: 'make test' implies 'make'
<sdb>a ha!
<snape>if you run 'make test', it will implicitly run 'make'
<snape>because it needs it
<snape>(but it's 'make check' usually :-))
<sdb>snape, thanks for the clarifications :)
<sdb>now "make check" is running. I have 4 cores. It seems from "top" that only one core is used.
<sdb>make --help did not give me any hints to how to build with multiple cores. Any ideas?
<snape>make -j
<snape>it's called 'jobs' in 'make --help' :)
<sdb>snape, but then this --help page is misleading because it says: "if no number is specified use indefinately many".
<nckx>sdb: That is correct.
<snape>yes, no number, but still '-j' :)
<nckx>Use make -j `nproc` for auto-detection & 1 job per core.
<sdb>this is unnecessary confusing. With guix build we have both jobs and cores (where jobs actually means build-jobs run concurrently by the daemon).
<nckx>How does this affect ‘make’ though?
<snape>sdb: make is 42 years old tool that has nothing to do with Guix (except for the fact that they are both GNU softwares)
<snape>(and that Guix uses it)
<sdb>I think our bootstrap-script should at the very least give a hint in the end about my number of cores and that I might want to run ".configure remembering the localstatedir (default /var) and then "make check -j N" next.
<Copenhagen_Bram>is it possible to herd start xorg-server in a different tty? I'd like to start a new X session without closing the current one
<snape>sdb: the thing is: There are some annoying bugs that happen when building Guile with multicores (at least there used to be)
<sdb>snape, yeah I heard about that. Make seems fine though it runs multiple CCX-jobs each using 1 core it seems.
<snape>so it's probably best not to do it. Unless it's resolved? I don't know, really
<sdb>snape, living life on the wild side ;-)
<nckx>I've run make -j [24] for ages and have never had a single problem. Can't speak for those blessed with more cores, of course.
<snape>make -j32 used fail while -j1 worked
<snape>*used to
<nckx>(That's a regex, not some mythical world in which I have 24 cores...)
<snape>oh :)
<nckx>Yeah. Clarity fail.
<sdb>snape, nice with 32 cores. Budget machine?
<snape>yes :) 128ram, 32cores (, 1200 euros
<sdb>this machine is fast! I resticted it to 800 mhz/core to avoid overheating (its a laptop with 1 little fan)
<snape>actually, we are two people using it, so we split the bill
<snape>(the other is m-o)
<snape>(not libreboot unfortunately, and I also discovered that while the machine was down, a new IP was still up, and on that IP was... a web server .... and that web server allowed to power on the machine)
<snape>so Intel BIOSes are pretty sofisticated
<nckx>snape: Hum. Ew.
<nckx>Such drool-worthy spex for the price otherwise.
<jonsger>civodul: I opened a pull request for the README file. Maybe you could merge it (if its okay) and then tag a 0.0.1 release. This would really help me for packaging it for opensuse, so I can update the guix package to 0.15, when its out :)
<civodul>jonsger: merged, thanks :-)
<jonsger>could you also tag a release?
<civodul>jonsger: will do, lemme fix at least the LD_LIBRARY_PATH thing
<jonsger>oke. thats nice. Bonne nuit!