IRC channel logs


back to list of logs

<nckx>mbakke: If you don't think it's noise 🙂 Done.
<sirgazil>Blackbeard: Remember the problem opening files in Thunar, Caja, and Nautilus on sway? It turns out you can work around it by adding (list glib "bin") to your system config as reported on
<sirgazil>I think I missed that bug report and reported mine because I searched for gio-launch-desktop is:open...
<sirgazil>This is one thing I don't like about debbugs and other issue trackers: that the developer is the one who says if an issue is fixed. But, in this case, the fix is not in production yet, so the problem is not fixed for the bugees.
<sirgazil>I tried the workaround in Thunar on Xfce, Caja on MATE and Nautilus on sway, and problem solved :)
<raghavgururajan>Hello Guix!
<jsoo>Blackbeard: I was confused forever about console fonts too. I think you can specify the full path, without a flag, too
<jsoo>raghavgururajan: hi raghav!
<jsoo>mbakke: how’s the cargo importer going?
<raghavgururajan>jsoo o/
<raghavgururajan>nckx So for time being (until I get my device back), I am using my friend's laptop. I installed guix on the ubuntu. I installed glibc-utf8-locales and exported the PATH variable. But still I get the error "Could not set locale". What should I do?
<Blackbeard>sirgazil: ah good. Somebody asked about it recently. Great to hear it has an easy fix
<Blackbeard>jsoo: in the installer,??
<guix-vits>Hi Guix.
<raghavgururajan>guix-vits o/
<Blackbeard>Hi ٩(◕‿◕。)۶
<guix-vits>nickname: PT***************S0 -- "are you sure you ain't mistaken login and password fields?"
<nothingmuch>is (concatenate-manifests (list (specifications->manifest '(...)) (load "some_other_manifest.scm")) idiomatic/good style?
<nothingmuch>fwiw the context is manifests in version control for the same project, the first is a daemon running on a service that fetches data, and the second is a jupyter notebook environment run on a user's machine, which inherits all deps of the daemon
<guix-vits>nothingmuch: i ain't dev; from my point of view you shouldn't worry about style so much with Lisp -- so long as modularity is there.
<guix-vits>"... we change them as our perception of model deepens, enlarges, generalizes until the model ultimately attains a metastable place within still another model with which we struggle." -- Foreword from SICP.
<Blackbeard>hello :)
<guix-vits>ok, you're win, folks: hello!
<Blackbeard>how do I change the make install flags
<Blackbeard>I have this right now
<Blackbeard>but it is not complete I think
<Blackbeard>I need to do something like this
<Blackbeard> make DESTDIR="${pkgdir}" BINDIR="/usr/bin/" install
<nothingmuch>guix-vits: i don't mean formatting etc, just the use of 'load' from a manifest
<nothingmuch>i didn't find any reason in the guile docs to suspect it's a bad practice, but in other languages that kind of stuff often comes with some baggage (search paths, changing interpreter state, etc)
<guix-vits>nothingmuch: You'll change it later, anyway :)
<nothingmuch>that's not what worries me, that's kind of a given, my concern is creating a mine field for anyone who comes after me since i'm not experienced with guile/scheme
<guix-vits>nothingmuch: "i'm not experienced.." + "not want to create a mine field" = /0 :) (but i'll stop my flood)
<nothingmuch>/0 ?
<guix-vits>nothingmuch: "division by zero"
<nothingmuch>i don't follow
<nothingmuch>basically, from a modularity POV i agree with everything you said, and this seems modular to me
<nothingmuch>but given my experience with other languages, treating a file of source code as a nullary function is an over simplification
<nothingmuch>so i just wanted to know if i'm walking into a trap
<nothingmuch>Blackbeard: is BINDIR appended to DESTDIR?
<nothingmuch>Blackbeard: i think make-flags would suffice, since the install phase includes it inthe make invocation, and those variables probably won't interfere with targets other than 'install'
<nothingmuch>if DESTDIR is like a prefix, then something like #:make-flags (list (string-append "DESTDIR=" (assoc-ref %outputs "out")))
<nothingmuch>(there are plenty of examples in gnu/packages/... fwiw)
<Blackbeard>nothingmuch: thanks :)
<guix-vits>nothingmuch: if your advice the same as (i can't parse :)
<nothingmuch>well, i didn't read that package's Makefile, so i don't know how it interprets DESTDIR and BINDIR
<nothingmuch>having "/usr" as part of BINDIR seems suspect to me
<nothingmuch>but (assoc-ref %outputs "out") will give an appropriate prefix for the package's output which can be supplied to make
<Blackbeard>nothingmuch: ok what you suggested worked
<Blackbeard>nothingmuch: however the package is not working :(
<Blackbeard>i think i'll have to set all of the flags manually
<nothingmuch>Blackbeard: not sure what you mean by manually. how does it break? does it install to the wrong path? does make install error?
<nothingmuch>if it fails with an error, please share build log
<Blackbeard>it install to the right path, but the binary is nested inside %outputs/usr/games/blobwars
<Blackbeard>so I can't do $blobwars
<Blackbeard>this is the makefile
<Blackbeard>and this is my build package,
<Blackbeard>I think I just need to adjust the flags
<nothingmuch>does BINDIR=bin do the right thing?
<nothingmuch>however, i think that won't be enough
<nothingmuch>i think the right approach would be to set DESTDIR=%out, BINDIR=/bin to override BINDIR=$PREFIX/games,and also set PREFIX=/ for other data
<Blackbeard>nothingmuch: i was trying something like that
<Blackbeard>this is my definition right now
<nothingmuch>i would try (list "RELEASE=1" (string-append "DESTDIR=" out) "PREFIX=/" "BINDIR=/bin"))
<nothingmuch>actually "PREFIX="
<guix-vits>nothingmuch, Blackbeard: as i'm understood, the Makefile contains the Defaults for all *DIR*. What about this approach: ?
<genghis-sean>Hey #guix! I'm having trouble running guix pull on a GuixSD installation. I just got a seg fault. Do you all have any tips to debug it?
<nothingmuch>guix-vits: you mean NieDzejkob's suggestion?
<nothingmuch>yeah, i think that's cleaner, actually
<Blackbeard>guix-vits: you mean using sed like fedora?
<guix-vits>Blackbeard: i'm not sure if it mean "(((sed)))" :)
<nothingmuch>is uppose (list "RELEASE=1" (string-append "PREFIX=" out) (string-append "BINDIR=" out "/bin"))
<guix-vits>nothingmuch: yes, NieDzejkob's one.
<nothingmuch>it's kind of iffy both ways because the makefile variable declarations don't provide a clean wayto set the basename of BINDIR
<Blackbeard>guix-vits: well I am not sure, the part you sent me is about werror, but that is already fixed
<nothingmuch>Blackbeard: see a few lines down
<guix-vits>genghis-sean: It's a x86-machine?
<nothingmuch>Blackbeard: oops, BINDIR will need a trailing slash, so (string-append "BINDIR=" out "/bin/")
<genghis-sean>guix-vits: yea x86
<nothingmuch>Blackbeard: why are you explicitly setting RELEASE=1 ? that appears to be the default
<guix-vits>genghis-sean: installed recently or this is happens after an update?
<Blackbeard>nothingmuch: ok I removed that
<nothingmuch>Blackbeard: you can also just set DESTDIR, and (substitute* "Makefile" "\\$\\(PREFIX\\)/games" "$(PREFIX)/bin") after unpacking
<nothingmuch>maybe that's a bit cleaner
<Blackbeard>i think it is working now
<Blackbeard>let me check, because I build over ssh
<genghis-sean>guix-vits: I installed it sort of recently. The last update was Feb 20
<Blackbeard>nothingmuch: it is working!!
<Blackbeard>sort of though, the binary runs but complains about missing fonts
<guix-vits>genghis-sean: can you roll-back and pull (yesterday pull on my x86 works) again?
<Blackbeard>i need to package blobwars-data too
<genghis-sean>Yea, let me try rolling back
<nothingmuch>Blackbeard: is that distributed separately? the makefile does try to install it (PAKNAME)
<Blackbeard>nothingmuch: yes it is distributed in a different package and url
<nothingmuch>does the buildpak target need to be run on that or is that something else?
<guix-vits>Blackbeard, nothingmuch: Fedora have some fixes for pak:
<guix-vits>"# SED-FIX-OPENSUSE -- Fix pak"
<guix-vits>not sure if this needed there, just in case.
<nothingmuch>i think USEPAK=1 is appropriate
<nothingmuch>it could also be passed as an argument
<nothingmuch>that would cause the $ALL variable to contain "buildpak", which would cause it to be built
<nothingmuch>as for adding $(LIBS) - no clue if that's appropriate, i guess if buildpak target fails
<Blackbeard>could you help me check something?
<Blackbeard>but I can't do tar -xvzf
<Blackbeard>$ file blobwars-data-2.00.tar.gz
<Blackbeard>blobwars-data-2.00.tar.gz: HTML document, UTF-8 Unicode text, with very long lines
<nothingmuch>that URL is the sourceforge mirror redirect thing
<nothingmuch>i think you want mirror://sourceforge/blobwars-data/blobwars-data-2.00.tar.gz
<nothingmuch>probably for blobwars-2.00.tar.gz too
<guix-vits>nothingmuch: `guix download ...` printed "following redirection to..." multiple times, but returned html too.
<Blackbeard>ok my bad
<Blackbeard>seems like the data is inside the same package
<nothingmuch>fwiw guix download mirror://sourceforge/blobwars/blobwars-2.00.tar.gz WFM
<genghis-sean>guix-vits: after rolling back I was unable to login through my normal user or the root user
<Blackbeard>nothingmuch: what is WFM?
<genghis-sean>It looked like the password was correct, but there was no desktop environment to load
<nothingmuch>i think just adding USEPAK=1 to the make flags will build the data from gfx sound music, etc
<nothingmuch>Blackbeard: "works for me"
<nothingmuch>i guess debian and other distros just package it separately?
<guix-vits>nothingmuch: yes: -- "_pkgname" used instead of "pkgname"
<nothingmuch>not sure what the rationale is, but i think a more guix-ish way to do that would be to have a single package with multiple outputs
<nothingmuch>i guess that would allow reuse of the data in case the code changes?
<nothingmuch>so saves space for binary distribution?
<guix-vits>genghis-sean: i'd similar: deleted user with UID 1000 and my user with 1001 become 1000; i was unable to login, because no access to home dir. idk about root.
<Blackbeard>nothingmuch: it worked!!
<genghis-sean>I rolled forward back to gen #2 and it seems like something is corrupted
<Blackbeard> this is the definition in case you want to try it guix-vits or nothingmuch
<genghis-sean>Yea, I wonder if a fresh install is in order. This time a shared library couldn't be found so my guix commands are aborting
<genghis-sean>I suspect the daemon may not be running
<guix-vits>genghis-sean: if that was not, try "manual" installation this time?
<nothingmuch>Blackbeard: sorry, can't ATM, i need to run off for a bit... i'm glad it works though, and i would read the guix manual on multiple outputs to see if the same approach as other distros makes sense for guix (i can't remember if identical outputs can be shared between different derivations)
<Blackbeard>ok :) thank iyou for the help
<nothingmuch>fwiw you don't need (string-append "USEPAK=1"), just "USEPAK=1" , and since you have a subsitute* already, maybe it'd be cleaner to substitute "\\$\\(PREFIX\\)/games/" with "$(PREFIX)/bin/"
<nothingmuch>i also forgot when it's more approrpiate to use snippets and when it's more appropriate to add another build phase for substitution
*guix-vits guix package -f Blackbeard_blobwars_reshaped_for_use_with_f_flag.scm ....
<Blackbeard>thank you nothingmuch :)
<Blackbeard>guix-vits: :D
<guix-vits>Blackbeard: seems to work;
<Blackbeard>guix-vits: wonderful
<genghis-sean>welp my computer seems pretty unhappy. I might just call it a night
<guix-vits>Blackbeard: i'd to add to your definition a (string-append "RELEASE=1")
<genghis-sean>I tried reinstalling guixSD and the final step failed. After going back through the steps the installer can't find any disks to partition anymore :/
<Blackbeard>guix-vits: oh it didn't work without it?
<guix-vits>without it `blobwars -version` returns (Version 2.00, Release 0)
<guix-vits>now its "... Release 1)"
<Blackbeard>oh ok
<Blackbeard>added :)
<nothingmuch>hmm, that's really weird, Makefile has RELEASE ?= 1
<nothingmuch>btw, (string-append "foo") == "foo"
<guix-vits>yes, at least in Debian page. Maybe source-forge tar has another ones?
<Blackbeard>nothingmuch: yes :) I already fixed that
<nothingmuch>guix-vits: yep!
<Blackbeard>yes source is 0
<guix-vits>genghis-sean: it's terrible to hear.
<genghis-sean>eh, shit happens. Hopefully I'll be able to squash the bug and make someone else's guix install go smoother
<guix-vits>Blackbeard: when game is started, there is a message at top right corner: "No Medal Key found - Online functions disabled", idk what it is.
<Blackbeard>Yeah I saw that
<genghis-sean>It looks like there are some open issues with the same error I got installing
<genghis-sean>I'll have to dig into that later
<guix-vits>Blackbeard: it's in ./src/init.cpp: "No Medal Key found..."
<guix-vits>in ~/.parallelrealities/blobwars/ there is, indeed, no any key.
<Blackbeard>guix-vits: ahh you are right
<Blackbeard>I didn't think much about it as it works
<guix-vits>Blackbeard: probably you're right ("The game also contains an in-game "Medal" service, which allows players to receive award notifications for performing certain tasks, not unlike the trophy and achievements system found on PlayStation Network and Xbox Live." -- Wikipedia)
<Blackbeard>Ah I see
<Blackbeard>So it is ok I guess
<Blackbeard>I will take a closer look tomorrow anyway
<guix-vits>Blackbeard: thanks; (not sure if this is an official site, though): (see "Links")
<Blackbeard>guix-vits: interesting
<Blackbeard>guix-vits: that is blobwars 1, now I get it
<Blackbeard>I was packaging blobwars 2
<Blackbeard>guix-vits: oh thanks for that link! they have more games :)
<guix-vits>Blackbeard: there is an link from Wikipedia:
***apteryx_ is now known as apteryx
<Blackbeard>Good night everyone :)
<Blackbeard>guix-vits: thanks :)
<divansantana>Is there a workaround to assist with installing node packages on guix? I think npm is not yet available in guix.
<efraim>we have npm, it's part of the node package
<efraim>not a lot of packages though
<guix-vits>efraim: Is the @url and @uref are the only <a> marks in .texi? (/doc, http vs https links)
<efraim>guix-vits: I have no idea, I don't have a good grasp of texi formatting. I normally just copy from other packages
<guix-vits>thanks, anyway.
<divansantana>efraim: oh, I thought we didn't. Great!
<rekado>guix-vits: you can take a look at the comprehensive Texinfo manual (in Emacs or another Info reader).
<guix-vits>rekado: "For the second edition we are particularly grateful (...), and to David Jones, TEX wizard extraordinaire." -- no way XD
*guix-vits is muggle
<janneke>efraim: thanks for the libstdc++ patch, that could enable me to remove one or two of my hurd patches
*janneke is now looking at a python build regression :-(
<janneke>"Fatal Python error: Py_Initialize: can't initialize time" -- this was one of the first things that I fixed by patching glibc, what could have happened?? Hmm
<efraim>janneke: :) I tested it with aarch64 and with powerpc, it feels like bikeshedding for aarch64 but necessary for other architectures
<janneke>yes; i didn't think of using another gcc version, arch-based; but the hurd has a similar problem
<PurpleSym>I’m getting a weird error when rebuilding python-sortedcontainers: importlib-metadata is not a direct dependency of this package.
<PurpleSym>Can anyone reproduce this?
<PurpleSym>(In fact it’s a dependency of python-virtualenv, which recently got a major version bump.)
<efraim>I was looking at the couchdb patch and it looks like there's a bunch of bundled libraries. Then I checked erlang and it looks the same. I wonder if we're doing erlang packaging wrong :/
<PurpleSym>efraim: I don’t know anything about erlang unfortunately. For couchdb I tried to unbundle the build system, but it did not work :/
<efraim>PurpleSym: so you sent the patch?
<PurpleSym>Yep, that’s me.
<nckx>PurpleSym: Indeed, virtualenv should propagate importlib-metadata for its run/plugin/
<nckx>Will do.
*nckx wonders why python-virtualenv propagates none of its inputs.
<efraim>looking at the files here it looks like debian builds it all together and then splits it into many many packages, so I don't think we're actually doing anything wrong with the building at least
<nckx>PurpleSym: Done on master.
<civodul>Hello Guix!
<janneke>hmm, maybe it has to do with the cross build (or /cough/ containerized build?)
<PurpleSym>nckx: Thank you!
<guix-vits>Thanks, nckx. if some link accessed by https doesn't throw an cert-error but redirects to http, this link should be written as http in /doc?
<guix-vits>i'm use curl to test https-accessebility in .sh
<nckx>guix-vits: If the server responds over HTTPS, even oddly, prefer HTTPS. Upstream can fix it later.
<nckx>(Similar to 369e4e966092395d0e03e56710fa78eaf71a5ef5:
<guix-vits>got it, thanks.
<guix-vits>last time i'd seen, i'd looked for this: (not got it in head yet)
<NieDzejkob>nckx: python-build-system's wrapper suffices for python-virtualenv
<nckx>I don't think so.
<nckx>Could you explain?
<nckx>NieDzejkob: I assume you're not talking about p-b-s's ‘wrap’ procedure (which wraps {s,}bin & doesn't seem relevant here), so am curious what you mean.
<NieDzejkob>nckx: oh, sorry, I glanced over the context
<NieDzejkob>I didn't realize virtualenv could be used as a library
<NieDzejkob>in this case it needs to propagate its inputs
<NieDzejkob>I'll push a fix
<nckx>I think that's the only way.
<NieDzejkob>oh I see somebody already did
<NieDzejkob>sorry for that :D
<nckx>I'm… someone?
<nckx>Nobody's ever told me that :'-)
<NieDzejkob>nckx: everybody told you you're noone so far? That's sad...
<nckx>I've been called worse.
<janneke>ah, my new bootstrap glibc is fubar'ed -- the conditional source patching to trigger rebuilds did not work, of course!
<janneke>nckx: not being called at all, that's bad
*nckx buys phone, waits for friends.
<nckx>C'mon this is what the adverts say happens.
<OriansJ>*friends reject nckx because of the phone he buys because he watches too many ads*
<OriansJ>nothing one can buy brings friendship, the closest thing commercially is hookers.
*nckx snorts while eating noodles.
<guix-vits>Sent patch. Please, if that will be committed, add: "Guided-By: nckx on IRC" to it.
<OriansJ>or employees depending on your capital allocation and who you preferred to be the fuck'd party to be.
<guix-vits>OriansJ: i'm not parsed your latest message. Can you explain it in simplier words?
<anadon>Good morning Guix!
<nckx>anadon: o/
<guix-vits>Great page:
<anadon>I'm having to train on a LIMS system, and I swear the entire field of programs here are terrible. And the documentation sucks. It is a heap of bad ideas whose owners think the cloud will save them.
<anadon>For something not guix related.
<nckx>Kind of Guix-related.
<sneek>Welcome back Veera, you have 1 message.
<sneek>Veera, NieDzejkob says: Don't worry about lambda expressions. It's a simple concept with a scary sounding name - a lambda is just a function that doesn't have a name
<Veera>NieDzejkob: oh then it's easy
<anadon>What is GWL's channel?
<Veera>in guix can't we have root user password
<civodul>anadon: i think you can discuss GWL things here
<anadon>Type in : s/called Wisp and if your familiar with Python/called Wisp and if you're familiar with Python/
<civodul>anadon: if you don't get a timely reply here, you can try the gwl mailing list :-)
<NieDzejkob><anadon> *typo
<roelj>anadon: Thanks, I'll fix that right away.
<rekado>is that wrong in the manual as well…?
*anadon does a papa Palpatine
<rekado>anadon: so did you look for /releases/gwl-0.1.1.tar.gz…? (I just saw that in the website logs.)
<anadon>Nope, just noticed something on the website.
<rekado>I’m only looking because someone keeps trying PHP exploits on the GWL website.
<anadon>That is not me. I have other things to do with my time.
<anadon>If you guys were to see my TODO backlog, it spans, I kid you not, 5 years.
<nckx>Veera: Guix System handles user passwords exactly like other systems (passwd, etc.).
<rekado>anadon: oh, I didn’t mean to imply that I suspect you for trying PHP exploits!
<Veera>Well the installation from did not go well
<nckx>So you can set whatever root password you want. Veera: Additionally, you can set a password in your system configuration, but it can be insecure if you don't do it right.
<Veera>But I did it with vm image and its working
<rekado>anadon: this stuff happens all the time, so I checked, and that’s when the request for the release tarball came in.
<Veera>But It is not allowing root login
<Veera>only guest is there
<anadon>rekado: Is it on 7.4? Everything got better in the 5 -> 7 jump.
<rekado>anadon: It’s using Guile, not PHP.
<anadon>Yeah, that isn't ever going to work then.
<rekado>I have to split my TODO every year. Every year 80% of the items in TODO move into my MAYBE file.
<nckx>Veera: Can you log in as guest and use sudo (or sudo su -) to become root?
<nckx>That's safer anyway. You don't need to run an entire desktop environment as root just to admin some sys.
<nckx>(That would include your browser. Not that doesn't apply, but it's still not something you want.)
<Veera>default login in vm img download is guest
<nckx>Veera: I'm going to answer questions about the VM image here, because someone might know more. Best ask in #guix then. You can try changing the username from ‘guest’ to something else and reconfiguring. Most things will happily keep working. Maybe all.
<Veera>how to change username
<nckx>Does the vm have a system configuration file? Usually /etc/config.scm.
<Veera>nckx: sudo su - is working
<Veera>yes it has /etc/config.scm file
<Veera>docs are quite clear
<Veera>I have to read them for basic understanding
<jboy>nckx: I didn't manage to grab the gitless package definition the other day, and the link now seems to have expired. Did you send it for inclusion in guix pkgs?
<Veera>A MSG: The Guix System ISO are not working with Qemu 3.1 in Debian 10 Buster
<Veera>A MSG: The Guix System VM img is working fine with Qemu 3.1 in Debian 10 Buster
<nckx>jboy: Eek. I don't know if I still have it.
<anadon>Veera: I ran into something similar in CentOS except with the 2.0 line. The image is geared towards Qemu v4.x.
<nckx>jboy: I didn't submit it, I thought you wanted to.
<anadon>There are older instructions somewhere which may work with older versions of Qemu.
<jboy>nckx: I just found a browser tab with the non-final version.
<nckx>(Assuming that means mine — it wasn't final, the description needed love.)
<jboy>nckx: yes, your version that lived at p.deb/1133736
<jboy>sorry, just didn't get around to it till now
<nckx>I'll never forget to reset the paste expiration drop-down again.
<Veera>anadon: instructions haven't changed
*nckx lied.
<Veera>The Guix has not been tested for older VM emulators
<Veera>As Debian stable lags behind official latest versions of sw
<Veera>Qemu upstream does not supports such old version as 3.1
<Veera>And you people have perhaps developed, build and tested on new versions
<Veera>Software and Hardware mismatch
<Veera>Official Qemu still has source for
<Veera>But they may not have been tested with every hardware and software released
<nckx>There was someone on the ML recently with a similar problem, although it might've been anadon. I don't have it handy.
<nckx>anadon: Did you have any success with those older instructions you found?
<jboy>do you remember why you had the comment "XXX remove" next to python-cached-property as native-input, nckx?
<anadon>I did not. What I ended up doing is installing Qemu through guix, then ran it there.
<anadon>It was me in the ML
<nckx>jboy: IIRC it should already be propagated by something else. If the package builds fine without it, it can go.
<nckx>anadon: Nice.
<nckx>Whee, 40000+ bug numbers.
<nckx>(Chillax, these are for all of GNU debbugs, not just Guix.)
<janneke>yeah, i got 40006! almost felt lucky
<civodul>party time!
<nckx>I remember the 20000s and I'm not even that ‘old’.
<nckx>Insisted the old man.
<bdju>Checking old emails, it looks like I was around mostly starting with the 29k-30k area.
*civodul wonders what their debbugs age is
<civodul>damnit, i must be old:
<janneke>civodul: the make-4.3 situation on hurd is terrible
<janneke>i built make-4.3 on debian (nothing guix'y), so full up to date glibc patches...
<jboy>so the answer to making sure code is properly formatted is "install emacs"?
<janneke>==> "574 Tests in 115 Categories Failed (See .diff* files in work dir for details) :-("
<janneke>it hangs, and worse -- so i guess i'll just have to diversify on package level and do something like: gnu-make-boot0 and gnu-make-boot0-4.1
<guix-vits>janneke: if any other tool can mimic "make" (in case something is easier to package)?
<dongcarl>Hi all, apologize for my absence as of late, trying to get back into the groove now.
<janneke>guix-vits: make-4.1 runs fine, gnu make is not something you want to do without; certainly not while bootstrapping
<dongcarl>Wondering what the best way is of adding a configure flag for all gcc versions >= 4.9
<nckx>jboy: Yes. You don't have to *use* emacs if you don't want to, there's an etc/indent-code.el script to format the code from the command line.
<janneke>dongcarl: boo for being away so long!!! ;-)
<dongcarl>Just add it to gcc-4.9 and let inheritance do the trick?
*dongcarl is glad janneke noticed
*janneke is happy dongcarl is back!
<janneke>yes, i think that could work -- what is your concern?
<dongcarl>janneke: I want to add the --with-glibc-version configure flag, which allows us to use glibc for things like ssp
<dongcarl>I've had to work around that by injecting the cache value at make time
<dongcarl>Something like
<dongcarl>make gcc_cv_libc_provides_ssp=yes
<civodul>janneke: with this many test failures, there might be just one tiny issue at the very core no? :-)
<janneke>civodul: sure, most probably
<dongcarl>The configure flag was added in 4.9, and has been maintained, so I'm thinking we should turn it on if we see that the libc input is glibc... I guess the tricky part is detecting whether a package _is_ glibc... Perhaps I'll just go by package name?
<guix-vits>janneke: thanks.
<janneke>civodul: it says "Killed!" on most everything
<janneke>could be just one rpc call, or just one glibc function
<janneke>i guess that's the test suite timeout...rpctrace shows it hangs:
<janneke>.... => task192(pid22798)->gsync_wait (19578944 2 0 0 0)
*janneke goes ask around on #hurd
<janneke>hmm, using another/parameterized gnu-make-boot0 isn't all that trivial
<civodul>janneke: if there aren't too many commits, perhaps a git bisect on make could do?
<janneke>civodul: yes, looking at commencement.scm just inspired me enough to take a look at make again; and i mean that in the most positive way possible :-)
<janneke>i did a rough bisect, make-v4.2 is not bug-free, but only 3 tests fail; so i only need to bisect the 4.3 series
*janneke goes to try writing a git bisect run script
<janneke>this is more inspiring that bisecting the missing glibc patch; i would hope free software becomes so wonderful one day that such thing would be a trivial task too
<janneke>*more inspiring than
<raghavgururajan>nckx So for time being (until I get my device back), I am using my friend's laptop. I installed guix on the ubuntu. I installed glibc-utf8-locales and exported the PATH variable. But still I get the error "Could not set locale". What should I do?
<anadon>raghavgururajan: Give up all hope
<janneke>omg gnu make has a 1000LOC bash "./bootstrap" script...
<raghavgururajan>anadon: lol.
<raghavgururajan>anadon: Any ideas?
<nckx>raghavgururajan: 1. Are you sure this is an error and not just an annoying warning? 2. Does your guix-daemon.service have Environment=GUIX_LOCPATH='/var/guix/profiles/per-user/<you!>/current-guix/lib/locale' LC_ALL=en_US.utf8
<nckx>It could be taken from root's profile too, but I actually recommend running your daemon from your own profile on single-user systems:
<janneke>nckx: interesting
<nckx>That way you won't have to remember to sudo guix pull once in a while.
<nckx>raghavgururajan: Or, really, just ignore this non-error until you get your laptop back.
<nckx>Because, guess what, it happens on ‘my’ Ubuntu system as well and I had no idea because I've become entirely blind to that message.
<nckx>Well, that's what I demonstrate above.
<raghavgururajan>nckx: Yeah, thanks.
<anadon>When I `guix install gwl` as per the manual, the `guix workflow` doesn't get added as an option. What obvious thing did I read over?
<raghavgururajan>nckx Also, during package transactions, I get "substitute: /gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)". Are they same warning?\
<dongcarl>Hi all, I'm getting an "unbound variable %build-inputs" on this short diff here:
<dongcarl>I know I'm probably doing something dumb, but would appreciate help
<nckx>raghavgururajan: Yes, this all indicates your daemon(! not your ‘guix’ command) doesn't have the right variables set. Hence the need to set them in the sysd service.
<nckx>substitute inherits them.
<raghavgururajan>nckx Gotcha! Thanks.
<nckx>dongcarl: %build-inputs doesn't exist until build time, and you're trying to use it at ‘guix time’.
<dongcarl>Ah yes, that makes sense!
<dongcarl>What would I need to refer to it at guix time? Is that even possible?
<nckx>I don't have much context, but can't you just use the variable name directly? Of if this is parameterised, the procedure's parameter?
*nckx goes to look at ze code.
*dongcarl is thankful
<dongcarl>I basically just need a way to refer to "the libc input of _this_ package"
<janneke>possibly (package-inputs <package>)?
<janneke>without looking at code, /me runs away again
<dongcarl>Hahaha I mean... Wouldn't that create a circular reference?
<nckx>(assoc-ref (package-inputs this-package) "libc")?
<nckx>I don't know when this-package is bound TBH.
<janneke>oh, *this* package hehe
<nckx>dongcarl: Why not use gcc-4.8?
<nckx>Why is (package-inputs this-thing) not guaranteed to be identical? Is there some magical sideways injection happening elsewhere?
<dongcarl>nckx: Yeah that might be best
<dongcarl>Well I mean it's common to rewrite the libc input for gcc
<dongcarl>at least in the usecases I use guix for
<dongcarl>I'll just do (assoc-ref (package-inputs gcc-4.8) "libc") then
<nckx>dongcarl: It's (I think, since I'm just making up most of the context here) like changing ‘version’ in inheritance: source doesn't magically update. Same here. If you want more magic you'll have to do it at build time, using phases, I think.
<nckx>Yeah. Anyone rewriting it will have to take responsibility, so to speak.
<dongcarl>Yup yup, I'll play around and post to mailing list if I run into anything, thanks again for the help!
*dongcarl stares at the endless nss tests
<dongcarl>Oh wait nckx you mean I should add the flags at build time using a phase?
<dongcarl>Okay I think I'm seeing what you're saying
<nckx>Er, that's a possibility to do what you want, yes. I do *not* know if it's worth it or a good idea, so don't put shoulds in my mouth 😛
<dongcarl>Haha yeah no worries, will give it a go tho!
<nckx>Good luck 😊
*dongcarl remembers that just a few months he added a 'make-gcc-libc procedure which is a better place to do this
<nckx>It does sound like it.
<janneke>civodul: haha 749a54d7a458dc6779936138caf40ce600a80052 is the first bad commit
<janneke> * job.c (child_execute_job): Prefer posix_spawn() over fork()/exec()
<civodul>oh, too bad, because posix_spawn is Better
<anadon>What is the difference between posix_spawn() and fork()?
<civodul>posix_spawn = fork + exec
<janneke>civodul: didn't "someone" write post patch for guile around that theme ;)
<janneke>it's really ironic, have you read the implementation of glibc's fork/exec on the hurd?
<janneke>anyway, workaround: ./configure ac_cv_func_posix_spawn=no *cough*
<janneke>"someone" needs to debug and fix this further
<civodul>janneke: that's a reasonable workaround
<civodul>the implementation of fork on the hurd is quite terrible
<civodul>it's big
<janneke>yeah, the mes c library does not support that yet, on the hurd
*civodul goes back home
<sirgazil>GNOME's dektop recording is working again. Maybe the workaround for the gio-launch-desktop thing fixed it (I'll check).
<Blackbeard>Hello :)
<Blackbeard> then I think it should be reported to the manual, so others know about the fix too :)
<sirgazil>I forgot how to close issues. Is it
<sirgazil>Yes, that's the one.
<lfam>sirgazil: You might find this page useful, too:
<lfam>All the different debbugs commands
<rndd>hello everyone!
<bavier>hi rndd
***matijja is now known as irk
***irk is now known as matijja
<anadon>Hi thrtr
<dongcarl>Hi all, is there a way to build my local checkout of guix without regenerating the `po` files?
***jonsger1 is now known as jonsger
<jsgrant>I'm trying to do a 'sudo guix system reconfigure /etc/config.scm' with modules from added channels in my ~/.config/guix/channels.scm -- I already pulled it both with my regular user and it shows up there -- how / where do I need to declare it for root user?
<jsgrant>Is there a file I'm missing in etc, or? I see historically there was just a 'guix channels command that seems of since been removed
<nckx>Why doesn't /root/.config/guix work?
<nckx>Even better: don't guix pull as root.
<jsgrant>Firstly, lol, because I didn't even think of that (might try that); Secondly, if we're not supposed to guix pull as root -- does reconfigure handle pulling the latest automatically, I guess and in a 'safer way'?
<nckx>jsgrant: You just ‘guix guix reconfigure …’
<nckx>*sudo guix, derp.
<nckx>That will use ‘your’ guix.
<nckx>If it's doesn't, something's amiss.
<jsgrant>But that's for a local user right, not global / host os? I'm trying to get my network card working
<nckx>And you can use ‘sudo -E guix’ to force the issue.
<nckx>jsgrant: No, for the system.
<jsgrant>huh, will try that in a sec then
<nckx>‘guix system’ always and only affects the system.
<jsgrant>That's a good point, lol
<nckx>And Guix by default configures sudo to preserve the relevant environment variables to make ‘sudo guix’ find your regular user's profile.
*lfam tests the latest certbot
<nckx>Which is why ‘sudo guix pull’ on Guix System will pull into *your* home, but set everything to be owned by root, so it's a really bad idea. It ‘works’ on some other distributions but not all.
<jsgrant>Ah, okay interesting
*nckx enjoys the sumptious elliptic curves of their switch to dehydrated.
<nckx>jsgrant: I hope I haven't made a mistake anywhere because keeping this straight is a mess, but ‘don't sudo guix pull’ and ‘99% of peeps shouldn't guix pull as root, ever’ are deffo true.
<nckx>* on Guix System.
<jsgrant>This is my spare box, so not 'too too worried' about breaking anything big -- but haven't messed with Guix for legimately like near 5 years now, so trying to half-remember the little I did know / learn, almost certainly is going to result in growing-pains regardless lol
<nckx>lfam: Does it bring anything fancy to the table?
<lfam>nckx: You know we gotta have the latest version of everything
<mbakke>git log -G has become my best friend when merging branches
<jsgrant>But def appreciate it; I would have probably used sudo for just about anything like I seem to do, by near default, on other distros
<lfam>I think the latest certbot adds some features regarding OCSP, nckx
<nckx>jsgrant: That's the problem. It's muscle memory for so many of us. Not guix pulling as root prevents you from accidentally using, say, root's year-old copy of Guix instead of your fresh one if you would type ‘sudo guix system …’ by mistake.
<lfam>I think that since 5 years, the guidance about working as root has changed a bit. It used to be more common to maintain a root Guix and an unprivileged Guix
<lfam>Now we recommend what nckx is saying
<nckx>‘Certbot will now renew certificates early if they have been revoked according to OCSP.’ Oh cool.
<nckx>‘I WONDER WHY’ 😃
<nckx>Dehydrated probably does not do that, luckily I was unaffected.
<jsgrant>Huh, it might not be an issue of the channels not being found afterall; Getting an error saying 'ice-9/boot-9.scm:2803:6: In procedure resolve-interface: no code for module' listing the given modules that channel should provide?
<nckx>lfam: The wide split between ‘foreign’ and Guix Systems doesn't help. ‘You should *never* have to ‘sudo guix pull’ oh you use Debian then you *must* sudo guix pull’.
<lfam>Yeah true
*nckx gotta go.
<lfam>C ya
<nckx>jsgrant: I wish you the best of luck.
<jsgrant>Peace nckx and appreciate it
<jsoo>Is there a way to make guix system vm-image images smaller? For instance if I specify that my vm image will not have guix installed, can the system profile replace the symlink tree?
<jsoo>I was learning a bit about tinyx and it seems like the functional package managers can do the same thing
<lfam>Can you clarify your question about having guix installed?
<anadon>I'm going to head out for the day. Talk to you all tomorrow.
<sirgazil>lfam: thanks for the debbugs link.
<jsgrant>Okay ... my mistake, figured it out; I tried to append the modules to the same s-exp as I had gnu to and not make a seperate one for each 'group'. Working now.
<jsgrant>Don't know how self-evident it is / was, but to be fair the example I saw was multiple s-exp so maybe I should've figured that out earlier lol
<jsgrant>Peace anadon o/
<rndd>how to add scripts that executes at the startup of guix? for example i want to add "feh --bg-scale " at start-up
<nckx>…aaand never mind I'm back. 😒
<nckx>rndd: I put that in my .xsession. Guix start-up is too early, there's no X session yet.
<nckx>Also, halp, I middle-buttoned 2.2 MiB of text into emacs and now it's gone out to dinner.
<nckx>Unlike me.
<rndd>nckx: thanks!
<sirgazil>Regarding not pulling as root, I think guix itself prints confusing warnings that I read as an invitation to do just that (
<nckx>sirgazil: Is this on Guix System?
<sirgazil>But I have never follow that advise since I installed the system because I trust nckx :)
<nckx>I agree, that's horribly misleading if that's the default. I use a custom sudoers, I guess that's why I've never seen that…?
<sirgazil>And, sadly, I've heard people here recommending pulling as root. So it is even more confusing.
<nckx>Problem is, there *are* (or at least *were*, I haven't kept up) good reasons to pull as root on non-Guix Systems. But never in the ‘sudo guix pull && guix install …’ sense. However, it was a way to keep your daemon up-to-date.
<nckx>This is why I recommend running the daemon from your user profile if that isn't the default yet.
<nckx>No manual syncage.
<sirgazil>Hmm, and how do you do that? I haven't touched the daemon ever. Is that documented?
<nckx>sirgazil: You'd edit /etc/systemd/system/guix-daemon.service to refer to /var/guix/profiles/per-user/sirgy/current-guix/bin/guix-daemon (and adjust any other relevant paths).
<nckx>Or whatever init system you use. Again, this is for foreigners only.
*nckx kills emacs.
<sirgazil>Oh, I'm not a foreigner.
*nckx puts the gun away.
<nckx>sirgazil: On Guix System, the daemon is part of the system profile you created with ‘guix system reconfigure’, so is updated along with all your other softs.
<nckx>It's not ‘special’ like on foreign distroes.
<Blackbeard>nckx: noo emacs 😭
<sirgazil>Ok, good.
<nckx>Blackbeard: One herd restart emacs and she's good as new. ♥
<Blackbeard>Wonderful 🙂
<Blackbeard>nckx: how do you start emacs server with herd?
<nckx>Blackbeard: User shepherd:
<nckx>(Replace .xsession with xdg-bloaty-mcbloatfoo if you use a DE, I guess.)
<Blackbeard>I use stumpwm :)
<ngz>Hello. When I run `guix pull`, I get the following error. "guix/ui.scm:1826:12: In procedure run-guix-command: synopsis: unbound variable".
<Blackbeard>nckx: isn't it better to use emacs --fg-daemon?
<nckx>Blackbeard: I dunno. Possible! Why?
<nckx>I am not an emacs geek.
<nckx>ngz: Testing.
<Blackbeard>Oh no reason just asking :)
<nckx>Whatever it does in the background, the Shepherd can still track & kill it so I'm happy.
<nckx>ngz: I cannot reproduce here, let me try on another machine. Are you pulling from Savannah? Any channels you might've forgot about?
<ngz>hmmm. No, I don't use channels yet. I still have GUIX_PACKAGE_PATH set. I'm surprised the error may come from there.
<nckx>ngz: I've successfully pulled on 2 machines, one of them definitely ‘stock’ so it must be.
<nckx>Unset it just to test.
<ngz>you mean export GUIX_PACKAGE_PATH="" guix pull
<nckx>If that would succeeds (and replace your guix command with a vanilla one with fewer packages), you can still manually invoke a previous Guix with ‘/var/guix/profiles/per-user/nckx/current-guix-n-link/bin/guix’.
<ngz>It succeeds with a "Nothing to do" message. So I guess the error was happening after a successful pull.
<jsoo>nckx: I think you would use --fg-daemon so stdout can go to a log file. Also systemd semantics required foregrounded processes the last time i used it.
<nckx>jsoo: Thanks. I've never even looked at emacs's stdout or used systemd, but that's good to know.
<nckx>ngz: Mmmmaybe. I'm not convinced. 🙂
<jsoo>when you start up the daemon there's some output usually and sometimes it can report errors which can be nice to have.
<jsoo>up to you of course
<nckx>Oh I'm sure. I've just never had to debug a start-up failure.
<ngz>nckx: Neither I am, but I don't have a better explanation. In any case, it does work now. Thank you.
<nckx>God I love Guix.
<nckx>Just knowing you won't backslide into an undefined mess increases the joy of working on/debugging anything. Respawn checkpoints for your peesee.
<Blackbeard>nckx: I don't know which is better or why. I just use fg-daemon hahaha