IRC channel logs

2019-07-17.log

back to list of logs

<civodul>hi evhan
<civodul>evhan: there are docs for some of it, typically the high-level bits
<civodul>otherwise you have to look at the docstrings in each module
<civodul>see https://guix.gnu.org/manual/en/html_node/Programming-Interface.html
<civodul>(among others)
<iu>Hello. What is equivalent of "aptitude why" in Debian for Guix? I just installed guix on Debian system and in process of writing simple package definition. "guix build" downloads substitutions for tcl(!). How can I check what is the reason?
<civodul>iu: ah! you can do "guix build your-package --dry-run" first
<civodul>and you can also look at the dot file produced by "guix graph your-package"
<civodul>it'd be nice to have a better tool to answer such questions
<iu>civodul: I already built it, so "guix build" outputs nothing
<iu>civodul: "guix graph" is too big. Well, thank you for advices.
<evhan>civodul: Thanks. I guess I was wondering if there's an HTML version of what I can access via ,d <foo> in `guix repl'.
<evhan>So, the docstrings. But that's OK.
<civodul>iu: you can also look at the graph of "references" (run-time deps), which might be smaller
<civodul>guix graph -t references your-package
<iu>civodul: thanks, it helped
<iu>Another question, why in all package defintions things are written like `(("foo" ,foo))? This repetition could be removed with trivial macro, isn't it?
<civodul>iu: most of the time yes, but not in the general case
<civodul>the string is a label that can be used to refer to the store item of the package on the right
<civodul>there's a rough plan to allow us to just write (list foo) instead but we're not there yet
<dwagenk>another question: how do I specify the version of a dependency listed in the inputs section of a package definition? the packagename@3.7 syntax doesn't work
<rekado_>this is madness. In the C part of Classpath “Java_java_io_VMFile_exists” returns “0” for “false”, yet the Java part in java/io/File.java evaluates “VMFile.exists(file.path)” to true, so it loops forever.
<rekado_>I have no idea why.
<civodul>nckx: for the record, guix.gnu.org is not yet the official home page
<civodul>i say this because i saw recent commits of yours that change it
<civodul>but it's hopefully a matter of hours at this point :-)
<civodul>dwagenk: the package syntax refers to variables
<civodul>so if there's a variable 'foobar-123' that actually refers to openssl 1.1, you might refer to 'foobar-123'
*civodul posted a '.guix-channel' update
<rekado_>enough Java for today
<rekado_>–> zzzZ
<dwagenk>civodul: thanks. will look into that tomorrow.
<wdkrnls>hi, is there a plain US laptop keyboard option in the installer?
<wdkrnls>all I saw were international versions
<wdkrnls>and the dvorak/colemak
<gnutec>test
<wdkrnls> https://www.gnu.org/software/guix/manual/en/html_node/Keyboard-Layout.html
<wdkrnls>the default should be the US keyboard, but that is not listed as an option. Very confusing.
<wdkrnls>But I guess this is operating system is a science experiment at this stage.
<wdkrnls>I suppose it's easy enough to change.
<civodul>wdkrnls: the default is the US keyboard
<civodul>if you don't specify a 'keyboard-layout', that is
<wdkrnls>yeah, that seems to be the case for the manual install
<wdkrnls>I was just trying to follow the guided installer.
<civodul>in the guided installer you can use US keyboard as well, and not intl/dvorak/colemak
<civodul>i don't remember what it's called exactly
<civodul>it may be that it doesn't come first, indeed
*civodul -> zZz
<wdkrnls>I
<wdkrnls>Are guix generations trees or tapes?
<wdkrnls>I guess I was reading them as a tape.
<wdkrnls>e.g. can I switch back 3 generations make a new generation budding of that one, and then resume from the previous "latest" generation?
<wdkrnls>alternatively, does making a new generation from the 3rd back destroy the old "latest" one?
<brendyyn>wdkrnls: tapes. the reason is simply that a tree would be complex and so its better just to keep it simple for everyone
<wdkrnls>thanks - that's what I was thinking it was, but wanted to be sure.
<wdkrnls>maybe guix environment makes it more tree-like?
<gnutec>Did .iso guix comes with gnome or I have to install?
<wdkrnls>at 1.3 Gb, you would think it has it. not sure though. I'm double checking my backups before taking the plunge
<eggard>hello, is there any place I can get a system install iso for aarch64?
<eggard>I want my system to be guix
<bavier`>eggard: I believe the best we have right now is the 'guix binary' download
<bavier`>eggard: you can install guix on top of an existing distro, then use it to stand up a guix system
<eggard>bavier`: oh, that sounds good! Is there a guide or will I have to go thru learning how to do it myself?
<bavier`>eggard: the binary installation process is documented in the manual, under 'Binary Installation'
<bavier`>eggard: after you've got that going, you can play with the 'guix system' tools, and maybe eventually take the plunge with 'guix system init'
<bavier`>eggard: but you might find that having just the package manager on a foreign distro is just fine as it is
<eggard>bavier`: ok thank you! I cant wait to try out guix
<quiliro>bavier`: What do you mean by "then use it to stand up a guix system" after "you can install guix on top of an existing distro"?
<bavier`>quiliro: something like 'guix system init config.scm /', but I've only heard of this working and have not tried it myself
<quiliro>bavier`: how is it possible to init the foreign system?
<bavier`>quiliro: I'm not sure of the details, but know I'm curious, and might just try in a VM now.
<bavier`>s/know/now
<eggard>Im assuming you would use a livecd
<eggard>and mount the "real filesystem" to /mnt
<eggard>and then use `guix system init config.scm /mnt`
<quiliro>but that would mean you would overwrite it...
<eggard>well, you would start with all ur partitions as empty right?
<eggard>ur looking to wipe ur system and install guix
<quiliro>so the live cd would be a foreign distro with guix installed in order to install guix system on the hord disk?
<quiliro>what would be the advantage over doing it with a live guix system ?
<eggard>quiliro: well, for aarch64, there is no live guix system build
<quiliro>eggard: thank you!
<quiliro>could not go to sleep with that in my mind
<quiliro>:-)
<eggard>quiliro: lol. I literally cannot fall asleep till 5 am
<eggard>and it's light outside
<quiliro>no distractions...i know
<quiliro>but all play and no work make jack a poor boy
<quiliro>:-D
<arescorpio>55 años me
<arescorpio>5 free distros
<arescorpio> labor of love
<ryanprior>Has there been any discussion of an official guix Docker image?
<ryanprior>I think it would be especially useful for people using nonfree operating systems who want to incorporate guix into their workflows.
<efraim>It should be possible with 'guix system docker-image gnu/system/examples/docker-image.tmpl' but I don't think we have an official one ATM
<efraim>It would also be nice for CI systems
<efraim>Guix is also packaged in opensuse so there's another possibility
<ryanprior>Using it in automated build and CI systems would be great.
<abbiya>how to get guix installed gui apps show in ubuntu app menu ?
<abbiya>guix install ungoogled-chromium
<abbiya>how do i see chromium in apps list ?
<abbiya>and how to get rid of the below warning
<abbiya>"/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
<abbiya>"
<NinjaTrappeur>Hey folks, is there a post/email detailing the motivations behind cuirass (why this project has been started/why hydra wasn't a fit for you, etc.)
<NinjaTrappeur>?
<rvgn>efraim Any luck with that libvirt/virt-manager issue?
<rekado_>NinjaTrappeur: there isn’t.
<roptat>hi guix!
<rvgn>roptat o/
<nckx>\o
<rvgn>nckx o/
<user_oreloznog>o/
<NinjaTrappeur>rekado_ :( could you give me a TL;DR? In query if you prefer.
<NinjaTrappeur>I'm pretty excited by cuirass and would like to better understand the scope of the project.
<Gamayun_>abbiya: Normally, guix keeps .desktop files under $GUIX_PROFILE/share/applications/ I think. You can copythe one for ungoogled-chromium or symlink it to where your distro / DE looks for them. I think ~/.local/share/applications should normally work.
<abbiya>ok
<abbiya>thanks
<Gamayun_>;)
<Gamayun_>abbiya: I think I came across the setlocale issue when I used Guix on top of another distribution, but I can't remember how I sorted it. So there's probably a solution around somewhere, maybe in the mailing list archives.
<abbiya>i have set the export stmt that it is throwing in the warning to .profile
<abbiya>still i get that warn
<civodul>Hello Guix!
<rekado_>hello!
<rekado_>civodul: BTW I tried restarting guix-daemon on the build nodes I reconfigured with “guix deploy”, but it did not lead to lots of options to be passed to the daemon.
<civodul>oh
<civodul>so that suggests the service upgrade didn't happen?
<rekado_>yes, seems so.
<civodul>hmm, weird
<civodul>do you have the IP of one of these machines so i can look around?
<civodul>efraim: looks like your overdrive is unreachable
<civodul>could you take a look?
<civodul>nckx: BTW, what's the status of yours? :-)
<rekado_>civodul: perhaps I mixed up IPs. I’ll try deploying again.
<civodul>ok
<civodul>efraim: oh actually that overdrive is no longer at your place, sorry :-)
<civodul>i wonder why i see your DNS in those logs
<rekado_>civodul: I just deployed to 141.80.167.151 (aka hydra-guix-20). I used deploy-berlin-node.scm with node id 20. It aborted with an error.
*civodul looks
<rekado_>logging on to 141.80.167.151 I see that it runs an ancient daemon
<rekado_>restarting it doesn’t change it.
<rekado_>guess it’s running an old shepherd as well…?
<civodul>oh indeed, that must be the reason
<civodul>guix-0.13.0-11.953c2de
<civodul>that prehistory by our standards ;-)
<civodul>*that's
<civodul>well shepherd-0.3.2 is the relevant bit
<civodul>it did not support service replacement
<efraim>If it were reachable then I assume the backup image was flashed and the ssh tunnel connected
<rekado_>civodul: okay, thanks for confirming.
<efraim>Rvgn I haven't taken a look at it
<rekado_>civodul: I’ll just wait for “guix deploy” to get a fix so that it completes the GRUB install
<civodul>rekado_: sounds good
<rekado_>If anyone has an idea why GNU Classpath misbehaves on core-updates, I’d be delighted to hear it
<efraim>Where is it broken on master for i686?
<efraim>I'm curious if that suddenly started working
<rekado_>I’m now building it with glibc 2.28 to see if that makes any difference.
<rekado_>I don’t get it.
<rekado_>java_io_VMFile.c returns the right value; VMFile.java simply exposes that to the Java side; File.java calling it gets the wrong value.
<civodul>rekado_: are you sure it's the code from this C file that's being called?
<rekado_>yes
<rekado_>I sprinkled countless fprintf statements all over GNU Classpath and the code in that C file is definitely when VMfile.exists is invoked from Java.
<civodul>could it be a type mismatch? like it returns (int)0 instead of the correct tagged 0 for Java integers?
<civodul>though i have no idea how type tagging works there
<rekado_>yeah, I was thinking along those lines.
<rekado_>but I also don’t really know how the C types are converted.
<rekado_>the type declaration is for a jboolean, which is really just an unsigned char.
<rekado_>something somewhere should take that 1 and turn it into a Java “true”.
<rekado_>I built with glibc 2.28 and there’s no difference.
<janneke>civodul: nice work on channels
<Dynamicmetaflow>Good morning Guix!
<jlicht>hey guix! stupid question, but how do I actually do *anythin* with a `guix system container' container?
<jlicht>:%s/anythin/anything/g
<Dynamicmetaflow>jlicht: Check this video from FOSDEM2018
<Dynamicmetaflow> https://archive.fosdem.org/2018/schedule/event/usingguix/
<Dynamicmetaflow>The GNU Guix package manager offers some useful and exciting features and properties, but with this comes some options about how to make use of these.
<Dynamicmetaflow>
<Dynamicmetaflow>This talk will explore different ways in which Guix packages can be used, and what these different ways offer in terms of distributing, reproducing, versioning and isolating packages.
<jlicht>thanks Dynamicmetaflow, I'll have a look at it once I'm home again :-)
<civodul>jlicht: you can spawn it using the script it returns, and you can then nsenter it or similar
<jlicht>civodul: but how do I know which pid to use?
<civodul>that's the tricky part :-)
<civodul>you need the PID of the container's shepherd
<civodul>typically i run "pstree -p" for that
<civodul>i'm sure we could do better :-)
<mbakke>civodul: Can you merge master into core-updates when you have time? There are some difficult conflicts in "your areas".. :-)
<civodul>mbakke: ah, i don't like difficult conflicts!
<civodul>:-)
<civodul>i'll take a loo
<civodul>+k
<Dynamicmetaflow>Greetings, I was wondering if anyone has used Guix in a setting to provision virtual machines that provide services / cloud apps to organizations
<Dynamicmetaflow>Somthing similar to this https://cloudron.io, but at a smaller scale
<roptat>Dynamicmetaflow, we would need to have service declarations for the services, but then it shouldn't be too hard
<Dynamicmetaflow>Hmm that's what I had imagined. I'm intersted in trying to find ways to provide non-profit organizations who use for example, google drive, dropbox, salesforce and them to transition to use nextcloud, syncthing and civicrm. Was thinking of having a Guix configuration that setups a machine for say one non profit and then sets applications / services
<Dynamicmetaflow>hopefully setting up the applications / services in a VM or so that they are isolated
<Gamayun_>Dynamicmetaflow: That sounds like a neat idea!
<roptat>that's definitely a use-case, but we don't have as many services as we have packages :)
<roptat>maybe you can help though?
<Dynamicmetaflow>Gamayun_: Thanks!
<Dynamicmetaflow>roptat: You mean that nextcloud, syncthing etc are not necessarily packages or services that are available?
<Dynamicmetaflow>I would be interested in helping out, right now I'm now trying to breakdown the idea into manageable chunks
<civodul>mbakke: mission accomplished!
<mbakke>civodul: That was fast, thanks!
<apteryx>yay; patch fininshed for properly supporting a Btrfs subvolume for the root file system in Guix!
<apteryx>works well :-) Now onto packaging one of the Btrfs backup scripts available for regular snapshots of root and home.
<rekado_>hmm, again we only have 4.5T free on berlin.
<rekado_>I wonder if the gc job to collect the disk images actually works.
<mbakke>apteryx: Nice! Did you write a system test for it too? :)
<Dynamicmetaflow>I was wondering if anyone who was maybe part of this chat, https://lists.gnu.org/archive/html/guix-devel/2017-05/msg00199.html if there was additional conversations about this in a different thread of offline.
<apteryx>mbakke: not yet! I'll look into it!
<Dynamicmetaflow>I too am interested in building a secure communications server
<pkill9_>sounds interesting
<pkill9_>i'm interested in the potential for guix to help facilitate self-hosting
<Dynamicmetaflow>pkill9_: Likewise, I've looked into yunohost and freedombox and would love to learn how to create somthing similar to that in Guix
<civodul>rekado_: i think it does, but we do "guix gc -F80G" or similar, so nothing gets collected until we reach that 80G ilmit
<civodul>*limit
<civodul>it should be more like 200G if it's still 80G
<civodul>but the effect will be the same
<samplet>Before I dive into it, is anyone working on GNOME Control Center on core-updates? It segfaults immediately.
<mbakke>samplet: Not to my knowledge. Maybe Kei, but he does not seem to be online atm.
<samplet>mbakke: Okay. I’ll see what I can do.
*civodul just renamed a patch with a file name that was too long
<roptat>civodul, at some point I'd like to fix my translation of the manual. You said you have done some work, does it mean you have already some fixes, or can I go ahead and and fix everything I can?
<rekado_>samplet, mbakke I’m not working on it. Kei wanted to push the GNOME upgrades over the finish line.
<mbakke>roptat: Did you find anything down the mariadb:bin rabbit hole? :-)
<roptat>mbakke, I tried to have lib output, but that doesn't work well
<rekado_>civodul: oh, I see. I thought we’d sweep up garbage sooner.
<roptat>the libraries are not installed by the package to the right output, and the binaries still refer to them via their path in "out"
<mbakke>roptat: Yeah... I tried both a bin and lib output back in the day and gave up, but don't recall the details :/
<roptat>and specifying LIBDIR= (assoc-ref outputs "lib") "/lib" doesn't work, because the result is a rpath containing /gnu/store/…-mariadb/gnu/store/…-mariadb-lib/lib ^^"
<mbakke>hah
<rekado_>the order for a replacement of the servers behind ci.guix.gnu.org that are hosted at the MDC got delayed because we noticed that the new servers would exceed our power limit…
<rekado_>so now we’re adjusting the order, looking for things we can buy without raising the power consumption too much
<rekado_>(that’s why I looked at the storage.)
<mbakke>ARM!! :P
<rekado_>mbakke: not going to happen, sadly.
<rekado_>we’ll get all our servers from our Dell contact, so we’re pretty limited there.
<rekado_>we’ll probably increase the amount of RAM and number of SSDs for each of the new build nodes.
<rekado_>it’s still going to be a full rack of stuff.
<efraim>Threaten to beat the Dell contact with his own ARMs? ;-)
<rekado_>heh
<minall>Hello guix!
<roptat>minall, hi!
<bendersteed>hi there everyone!
<Tirifto>Hello!
*rekado_ bikes to the data centre
<samplet>Huh. Kei added a patch for this two days ago, and it looks like it should fix the problem I’m seeing but it doesn’t.
<samplet>I think I’m running an older version somehow.
<samplet>Argh! It is fixed, I just forgot to reconfigure. >.<
<Tirifto>I recently ran ‘guix upgrade’, and it told me: Consider setting the necessary environment variables by running: [NEWLINE] GUIX_PROFILE="/home/tirifto/.guix-profile" [NEWLINE] . "$GUIX_PROFILE/etc/profile"
<Tirifto>The third line (starting with a full stop) confused me; is that a part of the command I'm supposed to run, or is it a separate command? What does the full stop symbolise there?
<roptat>"." is a bash alias for "source"
<roptat>not sure if it's bash specific or not
<Tirifto>Ahh! I completely missed that. Must be another command then. :P Thank you!
<roptat>that last line is the same as source "$GUIX_PROFILE/etc/profile"
<lispmacs>Hi, I'm trying to install Icecat on a little 32-bit netbook with 1 GB of RAM. Icecat installed from a substitute, but it is forcing compile of rust package. The compile is brutilizing my memory and compile has been going for like 12 hours. Can I tweak some guix parameter to use less memory?
<roptat>-c 1 will help I think (it asks guix to use only one core for compilation)
<roptat>(although I think some packages might not always respect that)
<arshin>hi guix, is anyone going to order Pinebook Pro?
<mbakke>lispmacs: Unfortunately Rust does not build on 32-bit yet :-/
<mbakke>So your netbook will be busy for a long time and then ultimately fail.
<mbakke>Not the best UX, I know!
<civodul>rekado_: thanks for the update re the new machines, interesting that power consumption is becoming the limit :-)
<civodul>roptat: "." is actually POSIX for "source", which is Bash-specific
<mbakke>civodul: The 'guile' build keeps timing out on core-updates for armhf.
<mbakke>We should probably increase max-silent-time.
<mbakke>I tried building it 'interactively' a couple of times, but cancelled after 24h silence, assuming something else was amiss.
<efraim>I plan on ordering the pinebook pro
<arshin>efraim: any info on how well RK3399 is on fully libre systems?
<efraim>Vagrant would know better than me, but I think the graphics code is targeting the 5.3 kernel
<mbakke>The Guix "binary installation" manual recommends fetching civoduls key from 'pool.sks-keyservers.net', because it is locked to version 1.0.1.
<mbakke>I think we should emergency patch it.
<bandali>i wonder if the pinebook could eventually be librebooted
<mbakke>"openal" hits an internal compiler error on i686 on the 'core-updates' branch: https://ci.guix.gnu.org/log/r2fjx9m75m9rifg2yjbnn853wqy2547n-openal-1.19.1
<civodul>mbakke: we can patch it in the 'version-1.0.1' branch
<civodul>it'll be automatically updated on-line, even :-)
<mbakke>woah :-)
<civodul>hey bandali
<lispmacs>mbakke: so, no rust on 32 bit, meaning no icecat, apparently... any suggestions?
<civodul>bandali, roptat: i think we're pretty much ready for the Big Switch
<arshin>bandali: does it need to be? U-boot is FOSS enough isn't it?
<civodul>mbakke: "./pre-inst-env guix build guile -s i686-linux -n" on core-updates says there are substitutes
<bandali>civodul, roptat, oh yeah? nice! do you want to try it today?
<bandali>arshin, i mean, i’d greatly prefer if it were
<mbakke>civodul: I meant for armhf-linux, sorry!
<bandali>civodul, also, hey :p
<efraim>Debian's build times for guile on various architectures: https://buildd.debian.org/status/package.php?p=guile-2.2&suite=sid
<mbakke>lispmacs: Epiphany or 'sbcl-next' should work.
<mbakke>Also ungoogled-chromium, but you'll have to wait a bit before substitutes are available.
<civodul>bandali: dunno if roptat is available, but i think we can do that
<civodul>roptat and i already checked a number of things anyway, so nothing terrible should happen
<bandali>civodul, sure, up to you, i’m in no rush :) if you prefer for roptat to be around too, let’s do that
<roptat>"Should" :D
<civodul>yeah :-)
<civodul>so roptat, WDYT?
<civodul>i mean everything* is working on guix.gnu.org
<civodul>(* everything we checked)
<roptat>I think we can switch
<civodul>alright, let's do that bandali!
<civodul>mbakke: i've started another Guile build for armhf, we'll see...
<mbakke>fingers crossed :)
<bandali>alrighty!
<civodul>efraim: does that read as "two days"?!
<efraim>Yeah, I assume it was a heavily loaded machine
<efraim>18 for alpha before it failed
<civodul>that's nonsense
<civodul>i mean it does take a lot of time, but two days doesn't sound reasonable
<bandali>civodul, would you prefer if /s/guix is redirected to http or directly to https?
<civodul>bandali: i think it could preserve the scheme?
<bandali>i think gnu.org is http by default, but sets some sort of header if the user visits https so that they’d keep being in https
<bandali>hmm
<civodul>either way is fine though
<efraim>I think the debian default is 1 build per core, regardless of RAM
<bandali>okay, i’m gonna try with a //guix.gnu.org but i kinda doubt it would work with our set up
<mbakke>Node added 2 million lines of code between 10.15.3 and 10.16.0, while removing ~200k.
<civodul>woow
<vagrantc>they should just release with the LOC as the version
<civodul>heh
<efraim>Doom-and-gloomers say they're dropping 32 bit support, but I assumed they really meant precompiled binaries
<str1ngs>spaghetti takes up a lot of LOC :P
<bandali>okay, it’s done: http://web.cvs.savannah.gnu.org/viewvc/www/www/.symlinks?r1=1.79&r2=1.80
<bandali>i think the cron runs every half hour or so
<bandali>now we cross our fingers :)
<bandali>if this doesn’t work, we’ll try the explicit protocol for now. let me know which one of http or https you’d prefer
<bandali>it’d kinda bad if we “downgrade” someone from https://gnu.org/s/guix to http://guix.gnu.org
<bandali>and on the other hand, i wonder if there’s anyone browsing guix’s website with a setup that couldn’t handle tls
<bandali>(assuming https://guix.gnu.org supports older ciphers as well)
<pkill9_>i have an idea: a browser extension that looks at the website you're on and if you're on a website that is related to a package, e.g. the home page URL or the source code URL, you press a key-combination/button and it launches a terminal and runs `guix environment --ad-hoc <package>`
<roptat>We could go with https
<lispmacs>so, what is a graft?
<efraim> https://buildd.debian.org/status/package.php?p=ghc&suite=sid ghx
<efraim>Ghc took longer than guile
<bandali>ok roptat
<civodul>thanks bandali!
<bandali>cheers civodul!
<civodul>lispmacs: see https://gnu.org/s/guix/blog/2016/timely-delivery-of-security-updates/
<civodul>or https://www.gnu.org/software/guix/manual/en/html_node/Security-Updates.html
<bandali>replied to the ticket as well
<mbakke>Guix has actually passed the 500k LoC mark itself. `cloc` reports 519447 lines of Scheme on 'core-updates'.
<lispmacs>civodul: thx
<civodul>mbakke: so we're still far from adding 2M LoC between two releases :-)
<civodul>which is probably good, anyway
<minall>Hello guix!
<minall>How can I load the linux kernel, need to do some reverse engineering, and I need to load it
<mbakke>minall: WDYM by "load"?
<minall>mbakke: What do you mena?
<Dynamicmetaflow>From the recent article that was posted on the blog with using Guix as devops tool, wondering if anyone else is using it for devops?
<mbakke>minall: Do you mean load as in a virtual machine, or as the kernel running on your computer, or something else?
<minall>I mean as the kernel, I'm getting low performance, and I think it may be the kernel, so if it is the kernel, I can have linux-nonfree and see what he loads to see if I can improve my performance, but still using linux-libre
<mbakke>minall: See this blog article for how to customize the kernel: https://www.gnu.org/software/guix/blog/2019/creating-and-using-a-custom-linux-kernel-on-guix-system/
<minall>mbakke: Thanks!, I'll check it out
<mbakke>You can point the package object to the kernel source tree of your choice.
<minall>btw, if I load the linux kernel and it improves my performance, then, is there something I can do to improve the performance of linux-libre?
<minall>Thanks!
<civodul>bandali: has the cron job run yet?
<mbakke>minall: I doubt you'll find a performance difference.
<mbakke>What problems are you having exactly?
<bandali>civodul, it doesn’t seem so, and i don’t have ssh access to the machine to check
<bandali>i’ll check with the fsf sysadmins
<civodul>ok, i'll try again later
<bandali>okay
<minall>mbakke: Basically, with any free distro (pureos, trisquel, guixSD) I have bad performance
<minall>With non-free ones, such as ParrotOS for example, which has propietary software, it runs well
<minall>I thought at first it was the driver, or the xorg, but in the logs of those 2, it load the module succesfuly
<mbakke>minall: What graphics adapter are you using?
<minall>Comparing GuixSD and ParrotOS, they didn't loaded the module 'openchrome', which is the one that's added when you install xf86-video-openchrome, which is the one I need, so the two loaded everything perfectly, and also, my device is supported throught free graphics, so everything should be the same
<minall>But even thought, I just have bad performance on free distros, and good on ParrotOS 'propietary distro'
<minall>But I still want to use guix, since is just, so guix
<minall>Oh, I have to go guys!, I'll connect in the afternoon, then I'll ask again
<minall>Bye
<minall>mbakke: Sorry for cutting you like this, but I'll connect later
<mbakke>I managed to build 'openal' for i686 on core-updates by giving it GCC 9 as an input.
<mbakke>GCC 7 hits an internal compiler error.
<dongcarl>mbakke: `--target=i686` or on an i686?
<mbakke>dongcarl: -s i686-linux
<dongcarl>mbakke: Huh... What's the difference between `--target` and `--system` again?
<mbakke>dongcarl: --target uses a cross-compiling toolchain, whereas --system is more like `--host`, i.e. Guix will attempt to perform native builds for that platform.
<dongcarl>mbakke: I apologize for my ignorance, but how can Guix attempt to perform native builds for that platform? Does it run a VM?
<mbakke>x86_64 could always run i686 natively :-)
<dongcarl>mbakke: Oh I see :-)
<mbakke>If you have offloading set up, you can use --system even for foreign platforms.
<dongcarl>Ahhhh that's smart
<vagrantc>and then there's qemu-binfmt-server
*dongcarl is happy he learned
<dongcarl>binfmt is cool
<vagrantc>er, service ...
<janneke>whenever i want to start a VM, i always first do: sed -e 's,-append ",-append "console=ttyS0 ,' /gnu/store/..../run.sh > rvm.sh
<janneke>so that i can start it without terminal/in an emacs shell and get text output: ./rvm.sh -nographic -m ...
<janneke>is there a better way, how do you all do that?
<civodul>janneke: i do that occasionally, it's not great
<rekado_>so we actually only have 42U in this rack, not 48U as we thought. So power won’t be a problem as we can’t fit as many servers as we thought.
<civodul>we should probably add a command-line option
<rekado_>Meh.
<civodul>heh
<rekado_>on the plus side: this means we’ll have even more money left to spend on better components.
<civodul>we'll build core-updates in a day! \o/
<rekado_>I wonder if we’ll have enough RAM to make /tmp a tmpfs; we’ll test this setup tomorrow to see if the performance boost will be noticeable compared to having /tmp on SSDs.
<rekado_>we’ll use ungoogled-chromium and gcc as test cases.
<civodul>yeah, some builds require a lot of disk space
<janneke>civodul: okay...yeah hmm
<Tirifto>If Guix tells me to run a source command (as in ‘source /some/path’), should I add that command to my profile (or bashrc), too?
<rekado_>Tirifto: do not add it to bashrc
<rekado_>because that is evaluated for *every* shell.
<rekado_>including shells that are spawned by “guix environment”
<rekado_>you can add it to ~/.bash_profile, though
<rekado_>that would only be evaluated for so-called login shells
<Tirifto>Ah! And ~/.profile will work fine, too?
<Tirifto>(My login shell crashes if I change XDG_DATA_DIRS to accomodate for Guix, and I've yet to proprely investigate that.)
<civodul>bandali, roptat, rekado_: redirects to guix.gnu.org are in effect, yay! \o/
*Tirifto can confirm for gnu.org/s/guix!
<Tirifto>guix.info still seems to work though, if that was in scope as well.
<rekado_>civodul, bandali, roptat thank you for the work!
<roptat>Yay \o/
<civodul>should we 301 guix.info to guix.gnu.org?
<roptat>Probably
<roptat>It's supposed to be the same website, no?
<civodul>yes
<civodul>BTW, we could also host the manual for the latest master at guix.gnu.org/manual/devel
<civodul>it's ~5 lines of config :-)
<roptat>Sounds good
<efraim>That would be great
<efraim>Sometimes if its been a while since a release I end up reading the sources for the service
<roptat>civodul, https://linuxfr.org/users/emeric_/journaux/mais-pourquoi-flatpak :)
<vup>:q
<rekado_>another weird thing about this ant-bootstrap failure is that other file tests work just fine.
<rekado_>it’s just the “exists?” test that’s performed when determining whether a temp file name already exists that has this weird behaviour.
<rekado_>there are hundreds of checks before and they all work just fine.
<rekado_>bizarre.
<grumbel>Is it possible to skip the unit tests when installing packages?
<Ryvius>Hello, I'm trying to verify my Guix install file, but gpg says it is not trusted. I have imported that key thing. What's wrong?
<rekado_>grumbel: not generally. You’d have to create package variants that disable the tests.
<rekado_>Ryvius: that’s fine.
<Ryvius>Then what's the point of the signature step?
<rekado_>Ryvius: you don’t trust the key because you haven’t used GPG to declare that you trust it. As long as the signature checks out everything is okay.
<rekado_>GPG’s UI is pretty bad…
<rekado_>UX even
<Ryvius>Okay... Maybe that should be added to the install guide. Normally warnings shouldn't be ignored
<rekado_>Ryvius: it’s a GPG thing… we only care about “good signature”, really.
<vagrantc>maybe adjust the instructions to use gpgv instead, which you pass a "trusted keyring" and it just reports weather one of the keys in the trusted keyring was signed it
<vagrantc>no weird UX issues around trust paths and so on...
<Ryvius>Guess user friendliness isn't the most important thing here huh
<rekado_>Ryvius: I don’t think that’s fair. You’re talking about the user friendliness of GPG, which we recommend to use for checking the signature to ensure that your download is authentic and not corrupted.
<Ryvius>Yeah but to someone with little gpg knowledge that error makes it look like the download is corrupted or something. If the warning is to be expected then why not just mention it in the install guide
*rekado_ goes afk
<lfam>Ryvius: We are interested in making the software user friendly, for sure. It's just that time and energy are limited so this particular issue hasn't been handled yet
<Ryvius>Yeah so I just suggested adding it, that's all
<lfam>It's the best short-term solution for this particular warning. I guess the word "warning" is really too alarmist for many readers
<lfam>It's really a shame but pretty much everybody gets tripped up by this step, unless they are already total wizards
<Ryvius>Yeah that's what I thought
<bandali>civodul, rekado_, roptat yay!
<Ryvius>So just mentioning it in https://guix.gnu.org/manual/en/html_node/USB-Stick-and-DVD-Installation.html#USB-Stick-and-DVD-Installation would solve it
<bandali>i tried the schema-less version first, but that doesn’t seem to work currently
<bandali>so for now, i’ve just set up a redirect to https
<civodul>bandali: that's ok
<civodul>roptat: this linuxfr article is interesting (grammatical errors aside)
<dftxbs3e>hey
<lfam>Hi civodul! Is it possible to update certain parts of the online manual between releases? Maybe we could mention the gpg warning that Ryvius saw, and also change the key fetching instructions
<dftxbs3e>civodul: do you know what's the progress about bootstrap switching to gcc-7? powerpc64le-linux-gnu support depends on it
<civodul>hi lfam! i just committed something that should update guix.gnu.org/manual/devel automatically :-)
<lfam>civodul: Wow :)
<lfam>dftxbs3e: GCC 7 is on the "core-updates" branch, which is in the early stages of being built and tested
<civodul>hi tech
<mattplm>Hi all, just installed GuixSD and I have a problem with icecat. The browser can't seem to display digits (font is set to default sans serif and other apps like emacs show digits perfectly). Any idea what could fix that?
<rekado_>hi civodul
<bandali>civodul, now only if i could get the rest of savannah pages off of CVS ;)
<bandali>sadly it seems rms insists on CVS -_-
<civodul>rekado_: i think you mean "hi mattplm", hi mattplm! :-)
<civodul>bandali: so it's rms?
<civodul>oh well
<rekado_>… wanted to change nick to “tech”, but that failed…
<lfam>mattplm: Can you check if anything in this discussion helps? <https://lists.gnu.org/archive/html/help-guix/2019-07/msg00080.html>
<civodul>lfam: regarding the key fetching instructions, as discussed with mbakke earlier, we should also update the manual on the 'version-1.0.1' branch
<civodul>could you cherry-pick the relevant commit(s)?
<lfam>civodul: Yes, I can do this in about 6 hours
<civodul>awesome
<civodul>it'll also be automagically updated on-line
*lfam is technically at work
<civodul>we're living in the future
<civodul>heh :-)
<dftxbs3e>lfam: okay, do you have any idea if it's used in bootstrap-tarballs package?
<Ryvius>Alright I've made it to the installer. If it says "No wifi detected" I'm just out of luck with my chipset, right?
<ison[m]>mattplm: The link posted by lfam is for someone using Guix on a different distro I think. But if you're using Guix System then in the suggestions which mention sourcing a profile you should use /etc/profile instead.
<lfam>Ryvius: Statistically, that's likely :(
<mattplm>ok will try that
<lfam>Ryvius: The free wifi drivers are included in the installer
<dftxbs3e>lfam: The problem is: "configure: error: *** binary128 floating point type (GCC >= 6.2) is required on powerpc64le." - Floating point format changed in glibc 2.25+ and that float format requires GCC 6.2+, so we can't use glibc 2.25+ for bootstrap binaries, problem: GNU Guix does.
<dftxbs3e>Format changed from IBM 128-bit float to IEEE 128-bit float
<dftxbs3e>for little endian powerpc64 flavour
<rekado_>dftxbs3e: you can change that for the specific target architecture, no?
<Ryvius>Nothing to do I guess, shame. But thanks for the help
<lfam>I'm not so familiar with that level of the system but it looks like bootstrap-tarballs ultimately uses the 'gcc' package
<mattplm>ison[m] lfam nope nothing did the job :/
<lfam>I mean, it uses something ultimately inherits from it
<dftxbs3e>rekado_: change the floating point format back to IBM? Well, more and more stuff in glibc 2.25+ tends to make assumptions on it so it's more and more or a maintenance burden
<dftxbs3e>What I would need is that bootstrap binaries are GCC 6.2+ instead of GCC 5.5
<rekado_>dftxbs3e: no, I meant the latter. Use a later GCC.
<dftxbs3e>I'm not sure how to do it
<rekado_>dftxbs3e: we already use GCC 7 on core-updates.
<dftxbs3e>for bootstrap-tarballs too?
<dftxbs3e>Or the rest of the system
<dftxbs3e>GCC 7 has a quite long bootstrap path, it's in C++
<dftxbs3e>I'll try compiling from core-updates
<dftxbs3e>I already did attempt this few months ago with samplet - but we concluded we should wait for more progress on GCC-7 support.
<rekado_>dftxbs3e: in the bootstrap chain we use even older GCCs.
<dftxbs3e>See, that's the issue :/
<janneke>dftxbs3e: ...and if you're on intel, core-updates does not have any gcc in the bootstrap-tarballs
<dftxbs3e>janneke: what do you mean? I have an x86 machine to bootstrap from, and I have a Talos II as my workstation machine where I'd like to run GNU GuixSD
<rekado_>boring Java update: VMFile.exists returns true no matter what I give it.
<rekado_>the C side does the right thing, the Java side doesn’t. ¯\_(ツ)_/¯
<ison[m]>mattplm: Did you source a profile and if so which one? Also do you see anything guix related when you run echo $XDG_DATA_DIRS ?
<rekado_>I bet that this is also why we’ve seen the original error that led me down this rabbit hole where resource files were not copied when they should have been.
<rekado_>I just can’t fathom how changes to core-updates could have had this effect.
<janneke>dftxbs3e: ah, you need to create a bootstrap path for a new architecture -- interesting
<dftxbs3e>rekado_: the bootstrap path would need to go that way for powerpc64le-linux-gnu: gcc-5.5 + glibc 2.24 -> gcc-7 + glibc 2.24 -> gcc-7 + glibc-2.25+
<rvgn>Hello Guix!
<civodul>roptat: the nginx location for *.pdf is no longer matched
<civodul>i wonder what happened
<roptat>How is that possible?
<civodul>i don't know
<civodul>did i mess up during testing?
<roptat>No, it seemed to work well before
<civodul>by IceCat cache is full of old 301s that we've changed in the meantime
<civodul>ok
<roptat>Can you give me a link to a pdf?
<roptat>You can clear your cache with Ctrl+F5
<civodul>roptat: https://guix.gnu.org/guix-refcard.pdf
<civodul>open() "/srv/guix.gnu.org/guix-refcard.pdf" failed (2: No such file or directory)
<roptat>Indeed
<roptat>What do the location blocks look like now?
<civodul>well, roughly the same as before
<rekado_>I fixed it.
<roptat>The website?
<rekado_>sorry for the confusion, no. ant-bootstrap.
<civodul>well, congrats anyway! ;-)