IRC channel logs


back to list of logs

<lfam>Wooooooow. So this baffling test failure in Go 1.11.5 was caused by the fact that they accidentally published the release as a tar bomb
<civodul>lfam: ouch, you'd expect them to have a well-staffed QA dept
*civodul -> zZz
<civodul>good night/day!
<lfam>civodul: It's reassuring somehow... that they also have difficulty making exceptional releases
<lfam>Good night!
<Copenhagen_Bram>hello! I seem to be unable to boot guix from a USB
<Copenhagen_Bram>I just burned guixsd-install-0.16.0.x86_64-linux.iso onto a USB drive and plugged the drive into a Lenovo Thinkpad t400 laptop with Libreboot installed. I selected the option "Search ISOLINUX menu (USB) [u]" and the screen blinks and returns back to the same menu
<Copenhagen_Bram>oh wait now it boots
<rofrol>g_bor[m]: Finally managed to add service
<CornBurglar>Hey, I'm on Fedora trying to use guix, but when I invoke 'systemctl start guix-daemon.service', 'systemctl | grep guix-daemon.service' yields 'guix-daemon.service loaded failed failed Build daemon for GNU Guix'
<Copenhagen_Bram>um check journalctl?
<tavoris>if I'm making a package with a git source, how do I determine the sha256?
<bavier>tavoris: checkout the desired commit/version/tag, then run `guix hash -xr /path/to/checkout`
<tavoris>bavier: your a gentile and a scholar
<Copenhagen_Bram>Will GuixSD handle a separate /boot partition?
<tavoris>Copenhagen_Bram: yep
***atw` is now known as atw
<Copenhagen_Bram>Will GuixSD handle an encrypted root partition and a separate /boot partition?
<nand1>yes. full disk encryption including /boot is not currently supported. fde with an unencrypted /boot is OK.
<Copenhagen_Bram>nand1: whoah.... last time I used GuixSD it was the exact opposite. FDE including /boot worked, but a separate /boot partition didn't.
<nand1>oh maybe I misunderstood
<nand1>your statement. sorry for the confusion.
<nand1>actually I must have just forgotten how I set mine up
<nand1>I just followed the manual
<Copenhagen_Bram>nand1: back up your config.scm right now
<Copenhagen_Bram>i didn't, i miss it ;-;
*bavier would like to not be building two version of webkitgtk...
<terpri>at least on uefi systems, FDE including /boot works, but the standard EFI partition is unencrypted
<tavoris> timing out for anyone else?
<tune>hint: After setting `PATH', run `hash guix' to make sure your shell refers to `/var/guix/profiles/per-user/brad/current-guix/bin/guix'.
<tune>I keep getting this line when updating
<tune>does it mean my path is wrong?
***benny is now known as Guest49608
***Guest49608 is now known as benny
***rekado_ is now known as rekado
<rekado>tavoris: better use the new default:
<janneke>hmm, it seems that guix offload [test] now needs guix repl
*janneke runs pull --branch=version-0.16.0 on build server
<rekado>yes, the use of “guix repl” simplifies the setup. You no longer need to make sure that GUILE_LOAD_PATH etc are set when logging in via SSH.
<janneke>rekado: thanks, yes that makes sense
<janneke>hmm, i probably need to reconfigure too
<janneke>yes, system reconfigure to 0.16.0 fixes the offload \o/
<balsoft>Hello everyone, active NixOS user here
<balsoft>Would like to try out guixsd (for the second time)
<balsoft>I use home-manager to manage my dotfiles, user packages and services
<balsoft>What is the closest alternative on guixsd?
<balsoft>I don't need any home-manager modules as I barely use them anyway, I mostly just use xdg.configFile, xdg.dataFile and home.file in my configs
<balsoft>So what is the correct way to write stuff to ~ at system activation?
<rekado>there’s no way to do this in Guix.
<balsoft>This means that guixsd is basically useless to me
<balsoft>It won't bring many advantages (I wouldn't count scheme as an advantage), while disabling me to use my current practices
<rekado>I recommend sticking with NixOS then.
<balsoft>Yeah, thanks for help anyway.
<balsoft>It's actually quite sad guixsd is lacking some important features, as I like the way it manages configuration more
<balsoft>And I also like that it uses the same language for package manager itself, configuration and tooling
<kmicu>There is nothing sad about it. It took many years to add home-manager to NixOS. Alas folks needing that feature did not send patches yet ;)
<g_bor>hello guix!
<g_bor>hello rofrol!
<g_bor>I am happy tht you could finally find it out
<g_bor>rekado: you just beat me on kcoreaddons :)
<g_bor>nice work
<civodul>Hello Guix!
<amz3>hello :)
<ngz>Hello. I think wine (and wine-staging) package have a small issue: they are not upgraded. It think the reason is the versioning used: previous release was 4.0-rc7 and the new one is 4.0.
<ngz>If that's the case, I wonder what would be the proper way to fix that.
<OriansJ>ngz: require explicit definition of latest that gets updated when a new version is added
<ngz>You mean, e.g., guix package -i wine@4.0 ?
<OriansJ>ngz: that is definitely one way to do it
<ngz>But it doesn't scale very well.
<OriansJ>well the definition of wine could just be a stub referencing the latest version and updated when new versions come out
<OriansJ>and it scales really well but it isn't very lispy
<ngz>I don't understand why it wouldn't be lispy.
<OriansJ>ngz: because it is duplicate code to deal with special cases
<ngz>This is what we do for a number of packages already, AFAICT.
<OriansJ>ngz: yes you are right
<civodul>ngz: "-rc7" is a release candidate, so not something we'd normally package
<OriansJ>civodul: only weird bootstrap edge cases right?
<civodul>OriansJ: edge cases for what? (i was referring to the "wine" package ngz mentioned)
<civodul>so, there's a kerning issue on the image at
<civodul>anyone knows how to get Inkscape to do the right thing?
<civodul>rekado_ maybe?
<OriansJ>civodul: where release candidates and non-standard releases are included in guix
<ngz>Silly idea: add a `version-suffix' symbol in `package' record, so we can refine `version-compare'.
<civodul>OriansJ: ah yes, we'd package RCs for software that hasn't seen a release in a long time, for instance
<civodul>ngz: we use the version string comparison routine of glibc, which is the Widely Accepted Standard™
<civodul>so i'd rather fix the version string of Wine than fiddle with that ;-)
<ngz>But it seems to fail badly here.
<ngz>Because 4.0-rc7 isn't very peculiar.
<ngz>I think Python uses, e.g., 1.0 and 1.0b2
<ngz>I assume strverscmp will fail there too.
<ngz>(I didn't check, tho)
<civodul>ngz: (version>? "1.0" "1.0b2") => #f
<civodul>strverscmp pretty well captures most common practices
<ngz>But it should be #t, shouldn't it?
<ngz>I mean, "1.0" is more advanced than 1.0b2
<ngz>b meaning beta or some such, per PEPXXX.
<ngz>(see if you care)
<ngz>strverscmp probably doesn't handle pre-releases, hence the `pre-release' silly idea.
<civodul>ngz: hah! well "everyone else" has 1.0b come after 1.0 i guess
<ngz>Perhaps we could rewrite strverscmp in Scheme, with an optional argument defining the rule set used. For example (version>? "1.0" "1.0b2" 'python) would return #t.
<rendaw>Hello! Been googling for a while, but can anyone point me to previous discussions/articles/help pages regarding using guix on docker? Tried the naive way of running on debian:stretch but no luck. Looking to set up a stable build on a CI service
<rendaw>I found a patch and some instructions on the mailing list from a couple years ago, but it's fairly hefty and risks turning this from a 1-night project to a 1-week project
<wigust>rendaw: why no luck? gpg missing key?
<efraim>stepmania FTBFS on aarch64 even after passing -DWITH_SSE2=NO
<rendaw>@wigust Ah, I probably panicked a bit when stuff started breaking, but the immediate issue is "In procedure getaddrinfo: Servname not supported for ai_socktype" trying to fetch packages
***rekado_ is now known as rekado
<rekado>civodul: I updated the SVG. Kerning should be better now.
<efraim>rendaw: I test my custom packages on travis-ci currently, but IIRC to run on docker the docker image would have to come with a running guix-daemon service
<rendaw>Oh, thanks! That looks pretty similar to what I have actually
<rendaw>Running guix-daemon isn't too bad for the sake of building, I just did `guix-daemon &` before trying `guix package -i`... hoping that's not the source of the error
<rendaw>At the least, it's good to know travis doesn't run as locked down as docker
<rendaw>although I'm not a fan, they were showing us someone else's private builds before and their support was completely unresponsive
<rendaw>I'll have to overcome that first
<Copenhagen_Bram>How do I disable substitutes in GuixSD installation? I want it to compile everything
<rendaw>Was missing /etc/services, but now I'm getting "guix package: error: build failed: cloning builder process: Operation not permitted"
<Copenhagen_Bram>oh that sucks
<Copenhagen_Bram>Which package module contains stumpwm?
<nand1>something like the commented out section
<nand1>I based it off of a thread on the mailing list
<nand1>I haven't actually tried it out but wrote it down
<nand1>if you install the emacs guix interface, you can hit e on the package and it will take you to the definition in the module
<nand1>there's an equivalent command line option that I don't recall
<efraim>nand1: looks like part of mark's config, I can confirm the extra-options work for not deleting sources or depenendencies of packages
<nand1>yes that's right. great. I will have to try it out
<pkill9>is it safe to remove ~/.cache/guix?
<ngz>efraim: About stepmania: what is the error message?
<efraim>ngz: on aarch64 it couldn't find sys/io.h
<efraim>this is after the WITH_SSE2=NO applied
<ngz>According to <>, using "include <io.h>" instead may work.
<efraim>I can try that
<efraim>trying to find somewhere to upload the armhf build log to
<efraim>armhf build log:
<ngz>This doesn't look good.
<Copenhagen_Bram>pkill9: mv it somewhere else instead of deleting it, and if something goes wrong mv it back
<efraim>ngz: just io.h didn't do the trick, still couldn't find it
<ngz>efraim: According to upstream IRC, build on aarch64 is "totally unsupported and unlikely to just work".
<ngz>Yet, according to the build log, this is so close…
<ngz>The Backtrace stuff is arch dependant.
<ngz>We're doomed =/
<ngz>efraim: Port to Aarch64 is in their TODO list. Meanwhile, what do you think about dropping aarch and arm as supported architectures?
<efraim>ngz: I think we leave it as-is for now
<efraim>might be like obs, someone seeing it fail will look at it long enough to make it work
<ngz>Subtle. OTOH, it's not the package everyone is going to use ;)
<pkill9>does anyone know how to fix the meson build error "Could not generate cargs for _____"? (where "_____" is a package dependency)
<rekado>you need to look at the logs
<rekado>could be a pkg-config error
<rekado>it could be, for example, that a library needs other packages to be propagated because the pkg-config file declares it in the “Requires” field.
<rekado>meson should give you some hints in the logs. I remember it’s not verbose enough, so you may have to run the pkg-config command by yourself in a suitable environment to get a good error message.
<pkill9>yes that was the issue. changing all 'inputs' to 'propagated-inputs' in the package dependency let it get built, thanks rekado
<ngz>OOC, has anyone installed GNU Guix on a OLinuXino?
<rekado>pkill9: it’s best to check which of them really need to be propagated.
<rekado>let’s not propagate all of them needlessly.
<pkill9>and the pkg-config file in the package dependency does indeed have a requires part
<pkill9>yeah, it was just to see if it would fix the build
<eubarbosa>lol, my Debian System has more Guix packages than its apt packages
<OriansJ>eubarbosa: the conversion process is nearly complete
<eubarbosa>OriansJ: Once I get to feel more comfortable with Scheme plan to move on to GuixSD... :D
<OriansJ>eubarbosa: actually one can do with very little scheme if one sticks to manifests
<pkill9>you can still write package definitions witha little cargo-culting :P
<eubarbosa>OriansJ: yep, Ive about manifests still need to learn about it, tho!
<pkill9>(without knowing much scheme)
*efraim totally got started that way, with liberal use of 'git grep'
<eubarbosa>pkill9: there are some important packages I miss on Guix and I want to channel those
<OriansJ>eubarbosa: just have to know (specifications->manifest '("name1" "name2" ... "nameN"))
<OriansJ>eubarbosa: what packages are those?
<eubarbosa>OriansJ: jdk 11 and npm packages....
<eubarbosa>Instead of asking yall I am up to learn scheme and collaborate it myself
<eubarbosa>I wonder how to pack standalone NPM packages, tho! ...
<OriansJ>well eubarbosa the jdk 11 is probably the easier to add; NPM is a nightmare for bootstrapping
<eubarbosa>OriansJ: yep, rekado explained about that, early! ... too bad!
<pkill9>what do you mean standalone npm packages?
<pkill9>like that you download from the website
<civodul>rekado: neat! how did you do that? (fixing kerning)
<OriansJ>eubarbosa: well it is what is expected when no grown ups get involved in making infrastructure in a community of people who think merging a pull request with an explicit Remote backdoor is 100% A-OK
<rekado>civodul: I looked at the kerning of the Guix logo text and then adjusted the kerning of the “Days” text for each letter.
<rekado>I used -0.9 as the kerning value.
<eubarbosa>pkill9: A way to containing NPM packages
<eubarbosa>OriansJ: lol
<civodul>rekado: oh, i presumed this was possible but didn't know where to adjust that
<eubarbosa>OriansJ: Too bad LSP packages are usually written in typescript and shipped as NPM packages
<eubarbosa>LSP servers
<rekado>civodul: it’s not so convenient; you can’t just change the kerning for all characters of the selected text. You need to do this once per letter pair.
<eubarbosa>maybe there is a way to build typescript packages locally
<eubarbosa>pulled directly from github
<OriansJ>eubarbosa: yes there is always a way; but sometimes the path requires hacking through a forest of bad decisions
<eubarbosa>Well, for now I will keep using VSCode for web development...
<OriansJ>eubarbosa: ever notice the node.js service VSCode spawns?
<eubarbosa>OriansJ: nope, what about that?
<OriansJ>eubarbosa: I suggest wireshark and example code if you don't have the Enterprise edition
<eubarbosa>OriansJ: I knew you would say that ... hehehe
<eubarbosa>I have no choice but to stick with it
<OriansJ>eubarbosa: work requirements or not comfortable with emacs?
<eubarbosa>OriansJ: work. Home-laptop is fully free hehe
<eubarbosa>Sadly, more and more all Web tools are getting more and more dependent on Google/MS/Facebook
<OriansJ>eubarbosa: Have a similiar problem myself; stuck having to deal with Windows 10 at work; You'll be amazed how hard people will stick their fingers in their ears and humm loudly when you provide proof WIndows 10 Violates HIPPA for an organization required by law to comply with HIPPA
<eubarbosa>OriansJ: gladly I dont need to deal with windows... yet
<eubarbosa>But Ive heard Emacs works fine under Bill's System...
<OriansJ>eubarbosa: I suggest emacs inside of virtualbox/vmware/etc with a share folder
<OriansJ>If it wasn't for virtual machines my productivity at work would drop by a factor of 20
<efraim>I believe I have a working package for dbxfs (DropboxFS)
<eubarbosa>OriansJ: Did you ever tried QEMU images under Windows?...
<civodul>hmm /gnu/store/yvh15v9s6xp6kx6pg1iagpj0hpg5ha0f-qt-5.11.3.drv systematically times out on berlin
<eubarbosa>I dont even recall how to run images with vb...
<OriansJ>eubarbosa: with and without hardware acceleration
<eubarbosa>thats great news !
<eubarbosa>At least I know I wont be at total loss if I happen to use Windows
<OriansJ>eubarbosa: the big problem we had was with fully encrypted /boot partitions is qemu with hardware acceleration tended to have a hashing bug, preventing the images from booting.
<OriansJ>But if /boot isn't encrypted but / is; the linux luks module works fine enough for proper boot
<eubarbosa>saving that tip for late...
<OriansJ>and unhardware accelerated qemu on Windows is very very painful for GUI work
<OriansJ>a shell only image is a little slow but not painfully so but gnome is like watching paint dry
<OriansJ>i3 or dwm is slow enough to notice but not enough to give up and just use Windows
<eubarbosa>I miss dwm...
<OriansJ>eubarbosa: easy to build and install with guix
<OriansJ>then set your .xinitrc to exec it
<eubarbosa>yep, DWM's default is kinda meh...
<eubarbosa>OriansJ: yep, Ive been using GuixSD Qemu image... SLIM/xsession, tho!
<OriansJ>eubarbosa: I Feel SLIM is the only acceptable option until someone ports it to wayland like they are doing for i3 with Sway
<eubarbosa>OriansJ: WayDM or WayMonad would be great too. hehe
<eubarbosa>A Scheme WM would be even better.... lol
<OriansJ>eubarbosa: I guess you haven't noticed guilewm
<eubarbosa>wow, installing it right now! hehe
<OriansJ>eubarbosa: it's documentation is quite sparse
<eubarbosa>oh, its X wm... I reckon once wlroots is released, wayland will receive lots of cool wm!
<OriansJ>eubarbosa: I think it is because the heavy lifting of making wayland development hasn't been done in a way that doesn't include massive frameworks like gnome or kde
<eubarbosa>too bad...
<OriansJ>well that is what wlroots is supposed to be for sway but even that needs alot more love before it allows a clean transistion for other projects
<eubarbosa>that is exactly what wlroots readme state
<eubarbosa>cool, wlroot has already Common Lisp bindings...
<OriansJ>eubarbosa: if half of software lived up to it's README; we would have colonized Jupiter by now
<eubarbosa>its seems there are a lot to do in wlroot
<OriansJ>eubarbosa: there is alot to do in all software and don't get me started on software security
<eubarbosa>Well, at least we know that our daily software need a lot of fix to be done... while Windows/Apple users cant how safe they really are
<OriansJ>That is a bad joke that gets very very ranty about people who literally couldn't find their ass with both hands, a flashlight, a GPS and map coordinates
<eubarbosa>I rather use an unsafe/unfinished libre products than closed products