IRC channel logs


back to list of logs

<leoprikler>I imagine someone will someday write a systemd service type and rewrite operating-system to use it
<Telc[m]>id really like to have use of it
<dstolfa>... if by then we don't have systemd++
<Telc[m]>guix is awesome with what it does do
<Telc[m]>but systemd is really awesome too
<dstolfa>Telc[m]: well, you're welcome to help with the effort, though it is a lot of effort i'd imagine. i don't think anyone will say: no, please don't do work for free! :)
<Telc[m]>its just a big bunch of useful software that i need
<projectmoon>new systemd kernel mode: kerneld
<dstolfa>Telc[m]: depending on what you actually need, you might be able to get away with just using systemd without it being the init and having libsystemd around
<Telc[m]>thats a lot of surface area thats already handled in pretty simple declarative way
<Telc[m]>journalctl would be nice in the short term
<Telc[m]>but its all the polish around the service files that i need for deploying servers
<dstolfa>Telc[m]: hmm, i'm not sure i still fully understand what your usecase is. obviously, you can make shepherd do all of this since it's configured in guile and you can write anything you'd like, but that's not really a useful answer
<dstolfa>is there anything specific you're trying to do, or are you just asking in general?
<Telc[m]>that would effectively mean cloning systemd in shepherd
<Telc[m]>what is needed by most of the industry is mostly the features laid out in that blog post
<Telc[m]>maybe someone has the ambition to do that in shepherd
<dstolfa>unfortunately that's the effort i was referring to earlier. guix system is configured in guile, not service files, so you would need to leverage existing guile definitions (maybe extend them) and then generate service files that systemd can read
<Telc[m]>but thats a big ask
<Telc[m]>yes that parts right
<Telc[m]>extending the guix service definitions to generate the files
<dstolfa>it's a bit unclear to me how this would look in the end. i can see it going two ways, one being an if for every service depending on some use-systemd? variable, and one in a discussion on what the interfaces should be and how shepherd could leverage this so that the init system effictively doesn't matter all that much
<dstolfa>Telc[m]: you could ask/propose something on the mailing list and see what others think
<Telc[m]>well presumably most services would just use the systemd service file
<Telc[m]>which could be pretty much a clone of the ones in debian etc
<Telc[m]>but with some method of overriding behavrious
<dstolfa>it's not quite that simple i think, because transmitting things out of bound is not ideal
<dstolfa>you wouldn't want to transmit service files out of bound because it kind of defeats the purpose of guix
<dstolfa>it would act a lot like running it on a foreign distro then
<Telc[m]>hmm i dont think thats true
<dstolfa>Telc[m]: how so?
<Telc[m]>its just different then shepherd
<dstolfa>how would you distribute the service files?
<Telc[m]>guix works with all kinds of other config files that it only lightly touches
<dstolfa>yes, but it generates them
<dstolfa>very few things are specified and transmitted out of bound
<dstolfa>for example, see openssh's configuration file generation:
<dstolfa>i imagine you'd need to do this for every single service that would need to generate systemd service files
<dstolfa>otherwise it kind of defeats the purpose, at least IMO. others may disagree
<Telc[m]>thanks, i was looking for an example :)
<Telc[m]>i "think" most distribution dont touch systemd files often
<Telc[m]>but i would bow to data on that
<Telc[m]>guix choosing to regenerate upstream systemd files for every service it ships
<Telc[m]>might not be a good strategy
<dstolfa>that's sort of how it works now with shepherd. maybe it would help to see how shepherd interacts with guix now on something like webssh (same file):
<dstolfa>the webssh-shepherd-service specifies what `herd start webssh` and `herd stop webssh` do, and then the `webssh-service-type` is usable and configurable by the user in scheme in their system configuration file
<dstolfa>but in general, the shepherd `start` and `stop` can be arbitrary code, including "run this in a container", etc
<dstolfa>which is what it would make it a bit difficult to maintain all of this and have it pluggable
<dstolfa>obviously, it would be nice to have multiple init support, especially with something like systemd
<dstolfa>but i think it's a lot of work :/
<Telc[m]>dumb question - define-record-type* creates the key value mapping to actual conf files yes?
<dstolfa>but i would still encourage you to maybe ask/propose something on the mailing lists to get other people's opinion, especially an opinion of those that have done a *lot* of work around this :)
<dstolfa>Telc[m]: there are no conf files, it's all configured in guile
<dstolfa>the record types are just a simple EDSL to write something that looks like config files, but it could look however
<dstolfa>it's just guile
<Telc[m]>nothing in etc for the daemon to consume?
<dstolfa>i guess there is if you count /etc/config.scm which does the operating system specification :)
<Telc[m]>ok right
<Telc[m]>so the edsl is used generically to produce text conf files or records for shepherd depending
<Telc[m]>im using guix FD so far
<Telc[m]>so i cant just browse my own system
<dstolfa>there's no configuration for shepherd, you simply specify what `start` and `stop` do, for example. the configuration in guile is used by guix to tell shepherd what to do when starting/stopping a service, but not by shepherd itself
<Telc[m]>what creates "/etc/sshd_config"?
<dstolfa>guix does, and i don't think it's in /etc
<dstolfa>well, guix-daemon does
<dstolfa>you can think of shepherd as an init-system-as-a-guile-library/interface
<dstolfa>guix exposes service definitions that are convenient to it, and then simply tells shepherd what to do rather than producing configuration
<Telc[m]>ok that makes sense
<Telc[m]>what is the method for the ipc? is it like calling wrapped c or guilesomething?
<dstolfa>hmm, i don't actually know
<Telc[m]>np its just a detail
<dstolfa>Telc[m]: skimming through shepherd code, it seems to be via sockets in guile
<dstolfa>but that's all i'm doing, skimming :)
<Telc[m]>that logical
<dstolfa>Telc[m]: in any case, i would encourage you to ask on the mailing list :). people have different opinions and ideas, and there are people with far more experience than me when it comes to doing this with shepherd
<Telc[m]>thanks for the help dstolfa I'm actually noodling through ssh.scm some more
<Telc[m]>looking at
<Telc[m]>that looks problematic for keeping an sshd file reconciled with upstream
<Telc[m]>ie it wouldn't lend itself to a basic diff with upstream
<dongcarl>Some feedback from the Twitter-verse (is this accurate?):
<dstolfa>Telc[m]: that's correct. unfortunately, to get the guarantees that you get with guix (rolling back the entire system to any generation, functional deployment and all that), all configuration must be immutable
<dstolfa>and thus, changes are regenerated as a new configuration file and the service is started in a way that points to it
<dstolfa>(but the old one still exists)
<Telc[m]>i think there must be another templating method being used as well
<Telc[m]>i dont see "computed-file" all that often when greping
<dstolfa>Telc[m]: computed-file is just a way of creating a derivation, there are others, but they all fundamentally work the same way
<dstolfa>Telc[m]: see
<dstolfa>dongcarl: also re that tweet, i think the only thing i can say is "sort of". they're probably making configuration changes to their OS config.scm, which will reconfigure everything if you just do a `guix system reconfigure`
<dstolfa>(and in turn, restart services)
<Telc[m]>thanks, reading now
<drakonis>Telc[m]: it doesnt use systemd and the bit about changes to services requiring restarting everything isnt quite right
<Telc[m]>drakonis: that wasnt me
<drakonis>the author of the tweet chain is in this very channel
<drakonis>he still wants to give guix a shot but he's not happy about its paper cuts
<euandreh>How can one count the number of untranslated messages in a .po files?
<roptat>euandreh, msgfmt -c ll.po
<ixmpp>weechat needs the SSL_CERT_DIR variable set
<ixmpp>is it convention in guix to wrap it to provide that
<ixmpp>or, what sets that?
<roptat>euandreh, sorry, not -c, but --statistics
<roptat>ixmpp, for guix to set it, you need a package that provides it, like nss-certs. I think the guix system provides one by default, but it's part of the further steps on foreign distros
<ixmpp>indeed, nss-certs has the folder
<euandreh>roptat: hmm, let me try that
<ixmpp>what i mean is, weechat (as is) doesn't work.
<ixmpp>because any tls server won't get validated, unless you pass that environment
<ixmpp>i'm not sure how that's meant to be solved
<ixmpp>is it actually broken, or is this a wontfix
<roptat>I don't think there's anything broken, SSL_CERT_DIR should already be set in /etc/profile (guix system) or ~/.bash_profile (foreign distro)
<roptat>(well, in ~/.guix-profile/etc/profile to be precise)
<ixmpp>wow, so it is
<ixmpp>i'm confused how i've ended up with a shell without that variable then
<ixmpp>very specific situation
<roptat>maybe the variable was not defined in that file when you opened the shell, and later added nss-certs or something that added the variable?
<ixmpp>i was in a vterm in emacs, launched by sway (launched by sddm, launched by shepherd)
<ixmpp>no, i've had nss-certs for months
<roptat>then, I don't know
<ixmpp>i think it's that that vterm shell didn't run the login profile?
<ixmpp>because the variables are in a shell i opened outside emacs
<roptat>pfew, added syntax highlighting for autoconf/m4: :)
<roptat>maybe emacs is interfering somehow?
<roptat>I had to trick the guile compiler to get it working though, it doesn't feel right
<ixmpp>yeah, emacs doesn't have SSL_CERT_DIR defined
<ixmpp>it's because emacs is emacsclient, and it's running in shepherd
<ixmpp>problem solved. sorry for the inconvenience
<MysteriousSilver>Hello #guix!
<euandreh>roptat: ty, it worked
<MysteriousSilver>leoprikler: so i just edited grub.cfg manually to boot into the other OS
<MysteriousSilver>i believe this will get erased in the next system configuration
<MysteriousSilver>but i rarely use the other OS, so its an okay hack i guess
<danialbehzadi[m]>I installed `python-pygobject` and `gtk+` packages.
<danialbehzadi[m]>But still get the `Namespace Gtk not available` error in Python.
<danialbehzadi[m]>Which package should I install?
<wirez>does guix have support for upside down monitors?
<ixmpp>sʍouʞ oɥM
<b__>cbaines, I don't know how to adjust your 0ad patches without making them in my own name in git
***b__ is now known as brendyn
***brendyn is now known as Brendan
***Brendan is now known as brendyn
<brendyn>nscd ha
<brendyn>has been using 8% cpu usage nonstop for days. not sure way
<sawshep>anyone developing with go on guix? it seems to be finicky with downloading and finding packages.
<sneek>sawshep, you have 1 message!
<sneek>sawshep, leoprikler says: adding stuff where it fits alphabetically is mostly a good idea, but sometimes things are in topical order (e.g. a bunch of packages are stuffed together because they're used alongside each other). As long as you don't put things at the end provoking merge conflicts people will be happy.
<zacchae[m]>How difficult is it to set up hibernate? It didn't work for me using default `%desktop-services`. `elogindctl hibernate` powers off but on powering up, I get a fresh session.
<ixmpp>How do i address this (@ (gnu packages gcc) gcc) package by specification? When i try i see "package 'gcc' has been superseded by 'gcc-toolchain'"
<brendyn>ixmpp, that package is hidden intentionally. it seems its intended for people to use the gcc-toolchain package
<brendyn>in this case its gcc-toolchain@7
<ixmpp>I know, thats why i wondered how to get around that
<ixmpp>But no worry, seems gcc --print-libgcc-file-name does it
<ixmpp>Or close enough
<brendyn>you mean you want to find that path in the store?
<ixmpp>gcc-toolchain doesnt have it, gcc does
<brendyn>i often use the fd command like this: fd ^$ /gnu
<brendyn>i found one in libgnt
<karthik[m]>Whats the npm equalent for guile ?
<mothacehe>hey guix!
<sneek>Welcome back mothacehe, you have 1 message!
<sneek>mothacehe, civodul says: re server timeout, bah, we must have missed another reason :-/
<leoprikler>dongcarl: regarding the tweet you shared it's slightly inaccurate in that `guix system reconfigure` ought to launch the new service, but it won't kill anything old, because that'd kill (among other things) the X session/virtual terminal you upgraded the system with.
<leoprikler>I'm sure a take this nuanced will survive in Twitterland
<leoprikler>zacchae[m]: I recently set up hibernation on one of my machines, but the result was that this machine doesn't really like hibernation all that much
<leoprikler>so there's definitely some "here be dragons" warning to be applied
<leoprikler>however, if you do want to continue, then cons (string-append "resume=" (car swap-devices)) onto your kernel-arguments, that ought to work assuming it's the correct swap device :)
<bricewge>Hello Guix!
<MysteriousSilver>bricewge: o/
<bricewge>When there is a file collision in a system profile, how can I choose which is package has precedence?
<leoprikler>IIRC you can't, guix picks the first one that applies
<leoprikler>(i.e. in another way you can, but it's brittle and undocumented)
<bricewge>Where can I find about the "other way"?
<leoprikler>the other way is specifying your packages/services such that this conflicting file first finds the one you want it to have
<bricewge>Argh, "whois" conflict with "inetutils" from %base-packages, it's gonna be ugly
<civodul>Hello Guix!
<bricewge>Is there a bug report tracking package collision and forcing precendence? I can't find it
***Kimapr7 is now known as Kimapr
<civodul>hi bricewge!
<civodul>bricewge: what do you mean?
<civodul>when you're pulling two different variants of the same package, for instance via propagated inputs?
<leoprikler>civodul more like two packages provide /etc/foo.conf, which foo.conf to pick?
<civodul>leoprikler: the last one wins :-)
<civodul>but i don't think there's an actual bug to report?
<leoprikler>yeah, but it's somewhat undocumented what happens and it seems brice has found a conflict in %base-packages that they aren't happy with
<mfg>Hi, is it possible to use the make-gcc-toolchain procedure to create a gcc-toolchain that uses musl? if so, how?
<civodul>mfg: hi! make-gcc-toolchain takes an optional 'libc' argument, so it should be possible to pass musl there
<civodul>never tried it though
<mfg>so (make-gcc-toolchain gcc-final musl) should work?
<mfg>or might work :D
<civodul>i think so
<civodul>might work, yes :-)
<civodul>i'm still getting report about substitute connection timeouts, "corrupt input", and the likes :-/
<civodul>do we have a lead here?
<civodul>i never seem to hit these issues myself
<boeg>Is there really no pactl in standard guix repositories? Is there something similar?
<nckx>boeg: Why wouldn't there be? It's part of pulseaudio.
<boeg>hmm cant find it
<boeg>and i pavucontrol running and working which uses pulseaudio
<boeg>maybe i'm mistaken
<nckx>Do you have pulseaudio installed?
<nckx>I don't mean running; installed ☺
<nckx>‘guix install pulseaudio’ or (packages (list … pulseaudio …)) in your system.scm.
<boeg>ah, i dont have the package, so i guess i have the dependencies other things bringin
<nckx>Guixness strikes again.
<nckx>(You'll get used to it. I promise.)
<boeg>ha great to hear :)
*nckx forgot to say hi all. Hi all!
*MysteriousSilver : o/
<mfg>i altered a package definition and saved it, but ./pre-inst-env guix build still builds the previous package. Is there something special needed to update the definition?
***Kimapr0 is now known as Kimapr
<nckx>No, it should build whatever (even uncommitted) you've made, immediately.
<nckx>What does ‘./pre-inst-env which guix’ return?
***Kimapr5 is now known as Kimapr
*nckx → luncheon.
***Kimapr8 is now known as Kimapr
<mfg>nckx: `/home/mfg/Documents/guix/scripts/guix' when i add packages guix also tells me those package are unknown
<nckx>mfg: That's correct. Then I'm not sure how this can happen. You haven't been messing with things like GUIX_PACKAGE_PATH or GUILE_LOAD*_PATH, right? Have you tried making ‘clean-go’ followed by ‘make’?
<mfg>no i haven't played with any env vars. this is after a git clean -fdx; ./bootstrap; ./configure --localstatedir=/var; make -j24
<nckx>I'm probably missing something obvious then. I've never been in your situation.
<nckx>Your problem, I mean. I do what you're *trying* to do daily; it should just work.
<mfg>it used to work exactly as you say, this is the first time it doesn't :D
<apapsch>mfg: by building the old version do you mean guix is just printing the old store file name without doing any build steps?
<mfg>apapsch: yes
<nckx>mfg: I hate suggesting this because it's essentially giving up, but: back up (for ‘later’ investigation when you have ‘time’) & fresh clone?
<nckx>If that still fails, well, at least it's data 😉
<apapsch>that happened to me as well with packages and also operating-system. it seems guix is not taking each and every bit of the definition into the hash value, thus some minor changes may not trigger a new build. I'm not exactly sure when this happens, but I had 'success' avoiding it by appending a build no in the version field
<apapsch>e.g. 1.2.3 becomes 1.2.3-1
<nckx>apapsch: Er what. Which ‘bits’?
<nckx>This applies only to metadata like description &c. Probably propagation. Things that *can't* affect the result.
<apapsch>nckx: ok, i had the wrong impression guix triggers build if the whole package expression changes, no matter what field
<mfg>So specifically i tried to change gcc-toolchain to (define gcc-toolchain (make-gcc-toolchain gcc-final msul)) to see what happens. This should be different enough i guess :D
<nckx>apapsch: Nope, it's cleverer than that. 😉 The good kind of clever though, it should never ever ‘miss’ something ever.
<nckx>mfg: define or define-public?
<nckx>Before we/you start debugging Guix itself, paste your patch & I'll try it.
<nckx>See in topic.
<mfg>my guess would be that make-gcc-toolchain assumes glibc as libc but i'm not sure
<nckx>Indeed, it's possible that your modified call is still pooping out a bog-standard toolchain in the end…
<mfg>also the musl package has no debug and static outputs but those are used in make-gcc-toolchain
<nckx>Good morning dstolfa.
<nckx>mfg: OK, so it kind of ‘works’ here, in the limited (and useless) sense that after applying your patch, ‘./pre-inst-env … guix build gcc-toolchain@7’ reports ‘guix build: error: gcc-toolchain: package not found for version 7’, which is new. So at least your patch has a (broken) effect.
<nckx>Guix is not confused, just being very tight-lipped…
<mfg>hm okay
<nckx>mfg: Indeed:
<civodul>we should provide gcc-toolchain for other versions
<nckx>Sure, but that's not the issue here; it's that Guix swallows that error.
<nckx>When not building with -f but simply editing commencement.scm to add musl to the default gcc-toolchain.
<nckx>Instead printing the bogus (well, ‘technically true’) ‘no toolchain for version 7’.
<civodul>ah sorry, i didn't follow the whole discussion
<nckx>NP, what you suggest is probably also true, not really a -taalchain user myself.
<nckx>* -toolchain (as fun as a pun as that is in Dutch, it was unintentional :)
<maximed>Hi guix
<mothacehe>hello maximed!
<nckx>Bonjour maximed.
<maximed>I'm much less occupied now (and coming days), so if anyone has some remarks / questions / ... on patches I sent, now is a good time.
<tricon>Greetings, maximed.
<efraim>vim-guix-vim updated, didn't mention the absurd bug I found during last minute testing
<mfg>nckx: thanks for investigating :-)
<mothacehe>maximed: I'd like to have a look to the meson cross-compilation serie soon, what's the status of the GCC patch?
<maximed>The GCC patch works for i686-linux-gnu. It turns out to be unneeded for i586-pc-gnu. It doesn't fix the build failure for aarch64-linux-gnu
<maximed>Personally, I'm interested in i586-pc-gnu. I intend to eventually allow cross-compiling 'complete' VM & installation images.
<mothacehe>ok fine, thanks. Some Guix System images depend of the aarch64-linux-gnu cross compiler so we'll have to fix it before merging core-updates anyways.
<maximed>I don't understand what's wrong with aarch64. Maybe big endian / little endian or something? Dunno
<maximed>So, the patch should be good for testing meson cross-compilation, but should probably not be merged until it's clear what the issue is.
<mothacehe>Agreed. Regarding, the sexp-contains-atom? procedure seems like a nice idea.
<bricewge>No, I want to get the whois binary from the whois package but it collide with inetutils' whois (from %base-packages)
<bricewge>And the whois package appear before inetutils
<bricewge>Is there a bug tracking how to specify a "priority" for a package when such collision appear, to chose which package win over an other one
<bricewge>It's not a conflict between package in %base-packages tho
<bricewge>I'll open a bug report, with something reproducible
<zacchae[m]>leoprikler: thanks for the info
<nckx>bricewge: *A* way is to install whois as you, not as a system package. Or remove inetutils altogether if, like me, you don't care about them. You get its ping{,6} binaries through %setuid-programs by default anyway.
<nckx>There is no Nix-like priority scheme.
<maximed>or Debian's priority and symlink scheme
<nckx>Never used that.
<nckx>Is it interesting?
<maximed>I think I used Debian's priority and symlink schem (I don't recall the name) to set the system-wide default text editor
<maximed>Choose between: ed, vi, nano, emacs ... . ed had the lowest priority
<MysteriousSilver>Dumb question, say i install a package without subsitutes (GNU Hello for example) , do the gnu-hello-2.xx.tar.gz files get deleted after i succesfully build it?
<nckx>maximed: What does priority mean in a system where users don't install packages? Like, as an admin, you'd presumably care only that ‘emacs is the standard editor’, not who comes third out of five. Unless something pulls in nano later. But maybe I'm missing something.
<maximed>MysteriousSilver: not directly, but eventually, yes
<nckx>MysteriousSilver: Unless you kept references to them some other way, they should be removed when you GC.
<maximed>(after "guix gc")
<nckx>I think Gentoo's update-alternatives worked like that. You chose ‘the’ compiler/editor/… for the system.
<maximed>nckx: Debian assigns some priority to various text editors. The one with the highest priority will be used as 'standard editor', unless the admin says: ‘no, ed should be sufficient for everyone’.
<tricon>But ed _is_ sufficient for everyone. It is the One True Editor.
<maximed>tricon: I'd like to see someone hacking on guix with ed.
<nckx>maximed: Ah, gotcha, that does makes sense across the entire package collection, not one installation.
<nckx>You sadist.
<nckx>We all know that xxd is the one true editor.
<nckx>Unicode support? Future-proof.
<tricon>nckx: Hah! I... I think you've got me.
<tricon>I dabbled with Acme one time. Something very charming about it, though it's a chore to use on a laptop without three mouse buttons.
<maximed>No, the one true editor is punched tape! To edit something, first let the computer punch it on a tape. Then, manually make new holes in the tape (or cover old holes up). Finally, let the computer read the tape!
<tricon>maximed: So the one true editor... is _you_!
<maximed>(Un)fortunately, this laptop doesn't have a tape reader / puncher.
<tricon>That is a USB dongle waiting to happen.
<nckx>tricon: Oh interesting. I've never tried it. I've never tried Plan 9 at all, for reason's I can't really explain.
<nckx>(Is Plan 9 free? On second thought, probably not, so shut up I shall.)
<maximed>tricon: yes! Just kidding though, I'd recommend emacs or nano.
<nckx>I spent an incomprehensibly long part of my childhood (years) using only MC's editor, so maybe I shouldn't be allowed an opinion.
<tricon>nckx: I go down the suckless hole now and then, and they refer to Plan 9 often. The Plan9 port is MIT license:
<tricon>Screen shot of Acme:
<mfg>there is also 9front, it even runs on a raspberry pi :D
<tricon>It's a mouse-based editor, based on some research that claimed that the mouse is faster in practice, according to some time trials that were done.
<dstolfa>plan9 sounded cool and all, but every time someone attempted to port its parts it ran painfully slow :(
<tricon>mfg: Quite interesting, thank you.
<mfg>tricon: beware, the 9front folks have a _unique_ humor XD
<nckx>tricon: Interesting. Whether true or flawed, it's always at least interesting when ‘someone actually did this research’ conflicts with ‘stuff all nerds know and accept’. Like Dvorak/layout of the year.
<dstolfa>also re acme: i think you can still use it
<dstolfa>even on linux
<nckx>mfg: ISWYM.
<tricon>nckx: The one testament I'll give about Dvorak as a Dvorak user is that it definitely saves on hand strain.
<tricon>I used to deal with some hand pain on QWERTY during high-activity weeks. I don't get that level of discomfort with Dvorak.
<tricon>But yeah, people get fast with nearly any layou it seems; and there are diminishing returns.
<tricon>That being said, I've dabbled with Plover/steno, and it is quite an exciting space. It's a time-sink to learn it though, but not really any more than switching to a new layout in general.
<nckx>Exact same, except I used Colemak for a very long time. It was fast. It was efficient. IT‌ FELT BAD. Dvorak is all that but IT FEEL‌ GOOD. My hands need to last a while. Years per layout is all what matters in the end, not WPM.
<tricon>nckx: "Years per layout..." Very good point.
<civodul>mothacehe: i got feedback from someone relatively new to Guix at work who found the Cuirass UI "hard to understand"
<nckx>dstolfa: I'm looking at acme-sac now.
<civodul>mothacehe: one conclusion we reached is that there could be tooltips or similar on the new icons
<nckx>I don't get it though. There's an .exe checked into the repo and the build instructions are for some proprietary IDE.
<tricon>nckx: Yeah, that's weird.
<mothacehe>civodul: yes, I agree some icons are a bit cryptic. If this person has tooltip suggestions, I'll be glad to add them.
<nckx>I only got here because someone said it was a Debian package, which seems false.
*nckx backs up the fun bus, searches onward.
<tricon>"Backsup up the fun bus..." LOL!
<tricon>I can't type today.
<tricon>Happy Monday!
<apapsch>I found this nice tool: though users are supposed to edit the source to configure it. there's also a config file, but its location must be edited as well
<tricon>There's a siren of simplicity to the idea of having one hand on keyboard and one on mouse for rapid selection a la Acme; but then I think of the reaching between keyboard and mouse that is still required and the thought of giving up Emacs as an editor/GUI/EXWM... and that's a hard sell for me.
<apapsch>a patch is pending upstream to add a cli flag for the config file. in the meantime, what is your stance towards having forks in the package source?
<civodul>mothacehe: not really, but maybe like "Dashboard" for the computer icon, things like that?
<civodul>that person was mostly ranting ;-)
*nckx .oO(oh, it's a ‘Debian package’ in the most awful sense:
<mothacehe>civodul: hehe, ok i'll keep that in mind :)
<mothacehe>I'm using Gitlab CI for a client and I must confess it is must easier to understand
<nckx>proto.h:134:14: error: conflicting types for ‘getline‘
<nckx>The worst part about excavating tombs is the smell.
<nckx>tricon: <There's a siren of simplicity> Finally, an argument for one-handed Dvorak for everyone :)
<dstolfa>nckx: let me know if you get it working, i haven't really ever used it. i've just seen people use it in the past
*dstolfa uses colemak because he found it to fix his right arm hurting from too much travel with the arm rather than just using his fingers
<nckx>This is suckless's 9base, an 11-year-old port of, well, older stuff. I don't have high hopes but I might poke at it some more during a bus ride or such.
<nckx>Unfortunately, just a regular bus.
<dstolfa>so... just SATA? :(
<nckx>dstolfa: Different keystrokes for—I'm sorry. But this is why I roll my eyes at the heatmap brigade. None of what matters to humans is captured in their silly microbenchmarks. Pretty damning when your subject is a HID.
<nckx>They also *really* hate pinky fingers for some reason. I think one murdered their family.
<dstolfa>yeah, the whole heatmap thing is a bit of a joke. what really made me stick to colemak was not having to move my right arm when programming, so my elbow was no longer rubbing against the table as much as it didn't hurt lol
<abcdw>hi guix!)
<sneek>Welcome back abcdw, you have 1 message!
<sneek>abcdw, ixmpp says: hey, any plans to sort out gtk themes, etc
<dstolfa>abcdw: hi!
<nckx>‘etc’ 😃
<tricon>One of the best things Emacs gave me was learning to palm the CTRL key. I use that technique all the time, even outside of Emacs, and I'll also palm the spacebar in games as I play right-side-keyboard (IJKL).
<dstolfa>tricon: holy crap i never thought of that
<abcdw>ixmpp: Not the first priority, but I thought about them, definitely home-service for it will be needed sooner or later.
<ixmpp>I just want dark theme tbh
<civodul>mothacehe: yeah, we discussed GitLab-CI too, but the thing is GitLab-CI has fundamentally less information to show, because it knows very little about what's going on
<abcdw>ixmpp: I put a todo, will take a look at it, when get some spare time.
<tricon>Fn keys that do not send scancodes are the bane of my digital existence.
<abcdw>Is it possible to disable following guile warnings?
<abcdw>;;; note: source file ./guix/scripts/home.scm
<abcdw>;;; newer than compiled
<abcdw>I saw, but seems code isn't merged.
<civodul>abcdw: yeah, one way to do it is (current-warning-port (%make-void-port "w")) as wingo noted in that thread
<nckx>tricon: But… they are the one true Compose key!! (Wayland is the bane of mine, because it doesn't let me map my Fn key without mangling the actual XKB definitions.)
<nckx>civodul: That looks dangerous.
<tricon>nckx: Does your Fn key actually send a scancode?
<nckx>Yes, but it's an ‘old’ ThinkPad.
<nckx>It's probably not fashionable now.
<tricon>nckx: I hear MSI laptops still send scancodes for their Fn keys. But yeah, the f'n Fn key has become firmware-locked, hot-garbage.
*dstolfa thinks thinkpads are more fashionable than any modern laptop
*nckx agrees.
<dstolfa>tricon: i think my precision 5550 sends scancodes
<dstolfa>i'm not 100% sure though
<tricon>dstolfa: I am jealous if so.
<nckx>You should come to a Guix meet-up to feel very fashionable :) The only MacBooks you'll see are very, very old.
<dstolfa>nckx: would love to once i'm vaccinated and can travel safely
<dstolfa>so... september
<tricon>I'm currently on a 2013 Das Keyboard. No Fn key whatsoever. I also have a Drevo with the Fn key between right-side CTRL and Menu, which is tolerable. I'm in the market for a new keyboard with very short pre-travel and no/rebindable Fn. key.
<nckx>FOSDEM is in February and I'm triple-crossing my fingers that it won't be ‘virtual’.
<dstolfa>nckx: conveniently, my girlfriend is from belgium and she has been dying to travel home... this sounds like a good excuse ;)
<nckx>It doesn't get much more perfect than that.
<civodul>nckx: yeah, binding current-warning-port altogether could hide useful things too; it's too coarse-grain, but that might be good enough in some cases
<bricewge>nckx: You're right, I have no need for most of the binaries it provides.
<bricewge>Is there another package providing "hostname" binary?
<nckx>Not in my profile, and probably not. Which is the problem with ‘most’: if you need hostname, I have no good answer for you.
<luis-felipe>danialbehzadi[m]: regarding python and gtk, maybe you need gobject-introspection.
<luis-felipe>danialbehzadi[m]: This is a hellow gtk app that works on Guix
***sneek_ is now known as sneek
<janneke>hmm, no guile-3.0.7 binaries for the (child)hurd yet?
*janneke tries to reconfigure their system
<roptat>"time guix --help" -> "real 0m4,730s" :/
<civodul>roptat: on an ARM board?
<dstolfa>i was about to say... wow that's long
<tissevert>hi guix
<dstolfa>hi tissevert!
<tissevert>o/ ^^
<civodul>roptat: that's terrible (it's .16s on my x86 laptop)
<roptat>I know the processor is not fast, but I wonder what it's doing
<tissevert>luis-felipe: what is the «entorno» command that you use in geteka's README ? is that an alias to some guix environment command ?
<civodul>it's 1.5s on my Olimex A20 though
<civodul>but that's an older Guix version
<nckx>Hi tissevert.
<roptat>I pulled yesterday
<roptat>(still building a new system ^^')
<civodul>roptat: it could be that i/o is super slow, that's often the case on these boards
<luis-felipe>tissevert: it's a script that uses guix API to manage my profiles more easily
<sneek>luis-felipe, you have 1 message!
<sneek>luis-felipe, madage says: sorry, I've been away and might have lost the context of your comment, was it pulseaudio?
<roptat>although, the fs is on an ssd
<civodul>roptat: i'd recommend "strace -c guix help" to get an overview, comparing cold cache/warm cache
<roptat>(that I didn't chose for speed, but electricity consumption)
<tissevert>luis-felipe: how can one use geteka.scm to run your demo app without this script ?
<civodul>what board is it?
<roptat>a cubietruck (cubieboard 3)
<luis-felipe>tissevert: the requirements directory has guix manifest, so you could pass it to guix environment, for example.
<tissevert>I see
<tissevert>I like to read clean manifests and see how people publish their software
<roptat>civodul, 50% of the time is spent in lstat64 (3055 calls), but the total is 0.09s
<civodul>roptat: what's the user/sys ratio?
<efraim>having just meesed with it, is the time different beween 'guix help' and 'guix --help'
<roptat>civodul, almost 10
<roptat>efraim, looks very similar to me
<civodul>it's the same
<tricon>I just picked up the PineBook Pro over the weekend. Hoping to get Guix running on it this week (haven't tried yet). If anyone knows of any ARM64 "gotchas", that would be much appreciated.
<roptat>when I run it, there's a long pause before it prints the help strings, until "COMMAND must be one of the sub-commands listed below:" and then a pause before the rest of the help is printed
<civodul>roptat: that's when it's scanning for command files
<roptat>I see
<civodul>roptat: could you open a bug, with the "time" command + output, the "strace -c" output, and anything you find relevant?
<luis-felipe>tissevert: Sorry for not providing "entorno". The geteka repository should not even be public, but I made it public to report a bug on Guile GI :)
<roptat>civodul, "guix pull --help" takes even 8s...
<luis-felipe>tissevert: Although there is nothing secret, just things that people should not use :)
<roptat>whereas guix package --help takes 1s
<tissevert>don't be sorry, I was just curious ! ^^'
<civodul>roptat: ok that one is something else, probably more like
<tissevert>really, I was curious what form geteka.scm would take, because I expected it to be a guix «package»
<tissevert>and seeing it was not, I was wondering what were the workflow you were using / suggesting for your demo app
<tissevert>(works here, btw ^^)
<abcdw>civodul: Did a dirty trick: 3>&2 2>&1 1>&3- | grep -v ";;;"
<civodul>uh :-)
<nckx>You crossed the streams.
<roptat>civodul, regarding this bug report, I have the same kind of timing as you, with my ssd, so I don't think it's the bottleneck
<roptat>unless the processor is limiting the io performance of the ssd
<civodul>roptat: it'd be great to do some more profiling
<civodul>i couldn't draw any clear conclusion back then
<civodul>it could be Guile's loader doing too much work, dunno
<abcdw>nckx: Uncrossed after grep)
<civodul>but for "guix help", we could also prolly reduce the amount of work done
<nckx>abcdw: *Thank you*.
<nckx>I'd not be able to sleep.
<roptat>how can I test the Guile loader hypothesis?
<abcdw>Updated version: guix BLABLABLA 3>&2 2>&1 1>&3- | grep -v "^;;;" 3>&2 2>&1 1>&3-
<civodul>roptat: profiling (resolve-interface '(gnu packages base)) is a good way to get started
<civodul>but the culprit could be the actual top-level code in those modules rather than the loader itself
<civodul>we can't really isolate the loader from the top-level code in the modules being loaded
<civodul>as in
<zimoun>What is the status of the core-update merge? And v1.4 in September, is it still realistic?
<civodul>zimoun: last discussion was
<civodul>simplified package inputs could be merged, though perhaps i should give a last heads-up so people can weigh in
<civodul>on the reduced bootstrap front, nothing for this round
<civodul>as for GCC 10, i'm not sure
<civodul>mbakke: did you have a chance to look into GCC 10 for core-updates? :-)
<zimoun>civodul: thanks! So I am up-to-date but I have not done yet my homework (about Julia ;-))
<leoprikler>luis-felipe which bug in guile-gi?
<danialbehzadi[m]>Hey folks,
<danialbehzadi[m]>I know the difference between `input` and `native-input`. But couldn't figure out the `propagated-input`.
<danialbehzadi[m]>Can someone explain it more?
<roptat>when you install a package, guix will also install the propagated inputs in the profile
<leoprikler>danialbehzadi[m]: A propagated-input is an input that needs to be installed alongside a package in a profile for that package to work in that profile.
<leoprikler>It's basically how traditional distros work.
<roptat>inputs that are referenced from the package are otherwise only added to the store, but not to the profile
<civodul>danialbehzadi[m]: also check out on inputs/native-inputs/propagated-inputs
<boeg>So when I start my machine up, I don
<boeg>so I dont have a login manager or anything, I just boot to tty1 - is there a way of having the "log in" prompt presented properly? It seems it gets presented and then afterwards a lot of "logging output" is presented so when i log in, its not in the "prompt" if that makes sense
<leoprikler>boeg switch to tty2-6
<boeg>leoprikler: hmm, i'd like to not have to do something like that manually :D
<boeg>what is the correct userlevel way to reboot/poweroff/suspend? Is there something like on systemd systems, maybe shepherd reboot or something?
<leoprikler>you can do herd shutdown, but you can also do the logind thingies
<leoprikler>for herd you need super cow powers tho
<boeg>leoprikler: alright, thanks
<boeg>and th elogind thingies is loginctl, right, leoprikler ?
<leoprikler>yup, but I hear it's also reachable through dbus
<ixmpp>Really could use a "reboot -f" btw
<ixmpp>Doing it through sysfs is less than tidy
<dstolfa>i just do loginctl whatever
<dstolfa>logind is pretty nice
<dstolfa>(elogind in this case)
<apapsch>oh damn, can I merge bugs into one bug? somehow I thought mails sent via git-send-email get automatically sorted into one bug
<abcdw>Have a good evening, guix!
<leoprikler>apapsch is it 49254~49258? I already merged them
<apapsch>leoprikler: thanks a lot!
<luis-felipe>leoprikler: regarding guile-gi problem, "the conversion of values of type GVariant to SCM was never implemented" (see
<Aurora_v_kosmose>Soon to be either using Guix System directly or in Qubes, depending on how bad support for the machine I intend to install it on is.
<Aurora_v_kosmose>(Support for Qubes, that is)
<projectmoon>guix librem 14 here we come
<xnnnx>Is there techical guide on making package definition ? For what to look for not and those that should be prosent.
<civodul>there's a Guile-Git issue that i can't reproduce, but it'd be "nice" if someone else can reproduce it:
<civodul>(it's also nice if we can just close it, tho :-))
<projectmoon>does DKMS integrate nicely into package definitions?
<projectmoon>and/or is it available in general? needed by a librem 14 driver
<Aurora_v_kosmose>DKMS feels a bit redundant with Guix. You'd just have dynamic modules, and some marker to disable CI building.
<Aurora_v_kosmose>Wouldn't you?
<projectmoon>there is this thing:
<projectmoon>i need this thing to be compiled into a kernel module
<projectmoon>the means by which i achieve this goal is mostly irrelevant :D
<Aurora_v_kosmose>Mhm. I mean that DKMS as a building framework is mostly a licensing hack.
<Aurora_v_kosmose>Ah, nvm. The way Debian uses it is distinct from its actual purpose.
*Aurora_v_kosmose really needs to stop trusting them as a source of truth
<Aurora_v_kosmose>projectmoon: Looking up how ZFS is done on Guix might be useful for reference.
<projectmoon>well, first i need it to boot
<projectmoon>right now it's just kinda... sitting there
<Aurora_v_kosmose>Unless they built it static. I'm not sure.
<projectmoon>grub boots up fine and has the guix boot entry, but after selectin git, grub just hangs at an empty guix screen
<Aurora_v_kosmose>Huh. That's weird.
<nckx>projectmoon: It's not availabe, and I don't think it would add value compared to the much simpler linux-module-build-system that already exists. DKMS a very hacky hack.
<projectmoon>Aurora_v_kosmose: will check the kernel line for any quiet mode stuff
<nckx>It's basically ‘how do we very statefully bolt some limited building from source onto a binary distribution’.
<projectmoon>removed the `quiet` parameter from the kernel boot line, but so far nothing different. was kind of hoping for something to pop out
<projectmoon>guess i can just let it sit there for a while o_O
<Aurora_v_kosmose>projectmoon: So this a newly installed system?
<projectmoon>yes, as of about 10 mins ago
<projectmoon>librem 14 uses coreobot
<projectmoon>which presents a normal bios. if that matters
<projectmoon>installation itself went fine
<Aurora_v_kosmose>I don't think that should be causing issues.
<Aurora_v_kosmose>Does Guix support whatever hardware is used for the graphics display by default?
<Aurora_v_kosmose>You'd be waiting a long time if it simply didn't support your GPU
<projectmoon>it's some intel graphics
<projectmoon>Intel UHD Graphics 620
<Aurora_v_kosmose>Fairly standard iGPU then
<projectmoon>do i perhaps need to add some graphics drivers to the system config?
<projectmoon>assuming i could get into it
<projectmoon>do the usual hacks of nomodeset etc apply?
***Kimapr6 is now known as Kimapr
<ecbrown> nomodeset nosplash at brub
<projectmoon>doesn't seem to have an effect
<projectmoon>still just hangs at the grub splash screen with nothing on it
<nckx>projectmoon: If you guix pull there's a librem-ec-acpi-linux-module now.
<projectmoon>nckx: that's great. but have to be able to boot into guix first 🙃
<nckx>In case it's still relevant, and it seems handy to have.
<nckx>What's ‘the GRUB splash screen’, exactly?
<projectmoon>grub starts up normally, with the gnu background
<nckx>‘nosplash’ doesn't do anything.
<projectmoon>can select the boot option, edit it, etc
<projectmoon>when starting the boot, the grub UI disappears, leaving the background
<projectmoon>then it just sits there
<projectmoon>whereas with the USB stick, grub disappears after a few seconds and the boot begins, and within 30 sec i'm at the installer screen
<Aurora_v_kosmose>chrooting it with a livecd to run the pull might be of use
<nckx>You could try to run ‘terminal_output console’ at the GRUB command line before booting, giving the kernel a text mode to which it may be more inclined to print something.
<projectmoon>i just sort of started installation again
<projectmoon>nckx: where do i add the librem module in the config.scm?
<nckx>I haven't switched over to it yet but ‘kernel-loadable-modules’ is the current bestest practice.
*nckx should.
<nckx>Just search the info manual for it.
<karthik[m]>GNU Artanis is the only web framework for guile ?
<roptat>You can also use the web server implementation from guile or guile-fibers, but it's not really a framework :)
<Aurora_v_kosmose>You can probably use FFI with any C-exposing framework.
<Aurora_v_kosmose>Natively though, afaik yes.
<apapsch>Aurora_v_kosmose: how about the php engine? :-P
<Aurora_v_kosmose>RPC time.
<Aurora_v_kosmose>Well that or hacking Guile into the engine and exposing it the necessary Guile objects.
<Aurora_v_kosmose>Probably far more bothersome than just using xml-rpc
<apapsch>before I attach the behemoth I'd rather take the guile speed bump
<projectmoon>nckx: ok. Does the installer do guix pull?
<nckx>No, by design. You'd C-M-F3 and do so manually.
<nckx>But whilst you'll want that module to make full use of your hardware, I'd be very surprised if it were required to boot.
<nckx>I'd focus on getting *any* relevant output from the kernel.
<projectmoon>Yeah will do
<boeg>is tor browser available in guix?
<boeg>I cant seem to find it
<roptat>no it's not
<roptat>it's very hard to build, but if you manage to, I don't think there's any reason to reject it
<boeg>good to know
<projectmoon>nckx: hit C for command line, entered the terminal output command, ESC, then booted. The terminal cursor just freezes 🙃
<dstolfa>hum, how do i get man pages in guix?
<roptat>dstolfa, with man-pages?
<roptat>(the package)
<roptat>(and man-db for the manual page reader)
<dstolfa>roptat: yep, that's the one. thanks
<dstolfa>i couldn't find it for some reason
<boeg>anybody run emacs daemon as a shepherd service or something similar instead of just starting it via .xinitrc or something?
<nckx>projectmoon: Did executing the command change the video mode? The background should have vanished and the text changed.
<nckx>boeg: Da.
<boeg>nckx: care to share how you did it?
<projectmoon>nckx: yes that part worked at least
***apteryx_ is now known as apteryx
<projectmoon>I didn't remove quiet though.
<projectmoon>Or add nomodeset
<projectmoon>But I'm gonna chroot next
<nckx>Note that you still have to start shepherd using whatever mechanism your DE/WM/whatever provides.
<nckx>I.e. I exec it in my sway/config.
<lispmacs[work]>just wanted to say thanks to whomever packaged up agate. I've got a live agate server running now
<raghavgururajan>Hello Guix!
<projectmoon>nckx: so in the chroot I don't have any commands. Isn't there supposed to be some links to set up paths to the GNU store?
<projectmoon>Like /bin is empty
<Aurora_v_kosmose>projectmoon: Normally a Guix executable should exist in the normal paths that then sets up stuff.
<Aurora_v_kosmose>Something sounds like it went terribly wrong.
<roptat>projectmoon, maybe /run/current-system/bin/guix?
<roptat>you'll need to run the daemon too if you want to work on packages
<projectmoon>Doesn't exist
<roptat>oh, it must be created on boo
<leoprikler>does anyone know why my local guix checkout reports 79% on all LOAD and GUILEC tasks?
<projectmoon>No /run/current-system
<projectmoon>Aurora_v_kosmose: yeah I agree
<roptat>since you're in a chroot, the normal boot process didn't occur, so it's normal that some stuff are missing
<Aurora_v_kosmose>Ah, so Guix does some first-boot stuff?
<roptat>mh, not first-boot, any-boot
<Aurora_v_kosmose>Ah, checks it everytime, I see.
<roptat>like, I just learned, setting a symlink from /run/current-system and /run/booted-system to the corresponding system generation
<roptat>probably, adding setuid programs too
<projectmoon>Ok that got me commands
<projectmoon>But yeah now the daemon and stuff
<projectmoon>Is not running
<projectmoon>I'm hoping updating will allow it to boot
<roptat>you'll need to mount some additional file systems to get it to work
<projectmoon>Which ones?
<roptat>(I always follow LFS for that)
<roptat>er... /dev and all that
<projectmoon>Those are in the chroot
<roptat>I usually follow that page:
<roptat>replace $LFS with your chroot mount point
<roptat>(from 7.3.2)
<projectmoon>But I guess I need to start the guix daemon or something
<projectmoon>Or make some symlinks?
<roptat>you can start the daemon manually, "guix-daemon --build-users-group=guixbuild" should be enough
<roptat>if you make symlinks, they won't point to the correct file from inside the chroot
<projectmoon>Says guixbuild group doesn't exist when I run guix pull.
<projectmoon>I have daemon running in background
<nckx>Users & groups are also created on boot.
<roptat>mh... could be that you never booted the system, so there's no /etc/group?
*nckx was away.
<nckx>roptat: Yes.
<nckx>That's why they're chrooting.
<projectmoon>Yeah haven't booted into the system
<projectmoon>Because I can't
<nckx>Hi raghavgururajan.
<roptat>ah, last time I chrooted, the system had booted in the past, so I had /etc/group and /etc/passwd
<nckx>projectmoon: I'm not sure what you expect to find in a chroot that will help solve that riddle.
<projectmoon>I dunno, maybe update or downgrade the kernel
<projectmoon>Getting info from it would be great though
<nckx>There won't be any if it never booted a good way into user space.
<nckx>Is there anything in /var/log?
<projectmoon>Will check
<projectmoon>Can I change the kernel in config. Scm during the install?
<roptat>yes, before reconfiguring
<projectmoon>Maybe downgrade to 5.10
<projectmoon>That's what pure os is on
<nckx>Yes, you can choose between the kernels linux-libre-{5.10,5.4,4.19,4.14,4.9,4.4} in addition to the default 5.12.
<nckx>Sounds good.
<roptat>see for the kernel field in operating-system
<projectmoon>Nothing in logs
<projectmoon>Guess I'll just try installing once more with an older kernel
<projectmoon>Also gonna check if other distros install
<nckx>You should test Trisquel if you have the time. If it boots, your hardware is supportable by Guix.
<nckx>If it doesn't, it might not be.
<nckx>Mm, never mind, I'm rereading the backlog and you used the Guix installer image.
<nckx>So it boots. Which kernel is running then?
<projectmoon>nckx: right. Manjaro boots fine.
<projectmoon>Trisequel uses old kernel right
<dstolfa>current trisquel is i think based on 18.04 so yes
<nckx>That I don't know, but they (like Guix) do not ship any proprietary software like blobs, unlike most other distributions.
<projectmoon>PureOS 10 runs, but is based on Debian 10 I think
<nckx>That's why I suggested it, not because of the kernel. But since the Guix installer shows up fine(?), we know your hardware can at least run Freely in framebuffer mode.
<dstolfa>if pureos works, it should be fine. pureos follows FSDG
<dstolfa>also pureos is based on debian unstable i think
<atuin>guix is generating a lot of duplicates in `subdirs.el`, is that normal?
<dstolfa>ah no, it's just following the debian unstable model by manually merging stuff from testing into their own "unstable"
<nckx>I'd try to install whatever kernel version the Guix installer uses, since the change could always be due to some configuration or dependency change, not just number go up.
<atuin>i have, for example, lots of entries there for dash, and it makes emacs startup slower
<nckx>Normal as in happens here too: . Normal as in intentional, probably not. Worth filing a bug and/or a simple (delete-duplicates …) patch.
<atuin>ok, so it's kind of a bug then :) thanks
<leoprikler>my bad, sorry :P
<nckx>I can't see which advantages could be indended ☺
<nckx>*tended, even.
<leoprikler>the advantage is obviously O(n) instead of O(n^2) in the profile hook ;D
*nckx right, duh.
<leoprikler>can ya paste me some manifest to test?
<leoprikler>nvm i got yasnippet twice in my own
<atuin>yes I can, let try to reproduce with few packages
<nckx>Haha manifests yes I should use those things
<roptat>what's the policy for updating the guix package?
<leoprikler><= 300 indirect dependants -> master
<atuin>leoprikler: `guix environment --ad-hoc emacs emacs-guix`
<atuin>that produces several duplicates :D
<leoprikler><= 900 indirect dependants -> staging
<atuin>seems emacs-guix is good producing duplicates
<roptat>I mean guix in (gnu packages package-management)
<leoprikler>or wait, I think it was 1500 on the staging
<roptat>I know the general policy :)
<leoprikler>everything else c-u
<nckx>roptat: ‘When needed’.
<leoprikler>oh, "the" guix package, not "a" guix package
<roptat>yeah :)
*leoprikler hits keyboard with head
<roptat>I need a guix package that contains the patch to the makefile, to build it in parts, so I can update my armhf system
<roptat>apparently the guile compiler doesn't have a concept of swap
<Aurora_v_kosmose>That'd be breaking abstractions, yes.
<roptat>it crashed with messages saying it was out of memory, when there was 20GB of free swap available
<roptat>(not that I ever needed that much swap, but I have a lot of disk space ^^⁾
<roptat>oh, interesting character
<Aurora_v_kosmose>That sounds like your system malfunctioned.
<Aurora_v_kosmose>Do you have a swap partition but didn't enable it with swapon?
<roptat>it was enabled, top showed that it was used, but not by guile
<Aurora_v_kosmose>...that's bizarre.
<Aurora_v_kosmose>You generally need to go out of your way to mark memory as unpageable, and it's mostly useless for anything but realtime systems and cryptography software.
<nckx>TIL Guile mlock()s all allocated memory For Increased Performance. /s
<Aurora_v_kosmose>I kinda wish pulseaudio would mlock itself though. I tend to have to restart it when it pages partly because it goes all scrwery.
<projectmoon>So for a different kernel version, it's not a string of the kernel name I guess
<projectmoon>Since the config file didn't work
<nckx>projectmoon: Could you rephrase?
<roptat>bah anyway, my problem is fixed on master, but I just need a new guix package
<projectmoon>What's the syntax of the kernel field, in example form?
<nckx>(kernel linux-libre-5.10)
<roptat>should I update to the latest commit on master, or to the commit that fixes my issue only?
<nckx>If you're trying to feed it a string, no that won't work.
<projectmoon>As I found out when it crashed the installation
<nckx>Also, use (gnu packages linux).
<nckx>Heh ☺
<projectmoon>nckx: What do you mean by the use?
<nckx>Depending on how you (or the installer) wrote your configuration, you'll have (use-modules (gnu packages …)) or (use-package-modules …) at the top. You need to add (gnu packages linux) to the former OR linux to the latter.
<nckx>Depending on which convention is used. They are entirely synonymous.
<leoprikler>atuin, nckx: fix is pushed 😋️
<nckx>leoprikler: That was fast. Thanks!
<nckx>You even ninja'd my thanks.
*nckx configures 😋️ instead of 😛
<nckx>The latter just implies ‘imma lick you’ in this font.
<dstolfa>nckx: yeah, the :P emoji looks really weird in some apps
<dstolfa>all of these emojis look weird in irssi to be fair
<Aurora_v_kosmose>In weechat too
<Aurora_v_kosmose>Emoji's weren't really made for terminal monospace display.
<hrnz>it healily depends on your typewriter emulator
<nckx>I was bored and added some emoji (well, ‘Unicode’) to GRUB and Unifont renders them nicely across two cells.
<nckx>So GRUB > irssi. 👍
<dstolfa>well, to me that appeared as a little box as 01F\n44D
<dstolfa>that's how well the emojis work in my irssi
<nckx>Someone got caught pissnetting.
<nckx>Aurora_v_kosmose: Never mind, off-topic. Thought I was in a different channel TBH.
*apteryx wonders what other channels nckx is in
<projectmoon>Hmm so purism people pointed me to their forums
<projectmoon>There's a post in there that's similar to my problem
<nckx>Oh, wait, you're using Heads?
<projectmoon>Don't think do
<projectmoon>Just core boot
<jab>dstolfa: thanks for the tip about my old irc nick. I'll change that now. :)
<jab>nckx: I think you were asking me about my old Dell Optilex 7020 machine's power. It's 30 GB of RAM, 3 terrabtype HDD. It cost me $250....ummm I don't know much about it's power just yet.
<nckx>Yes I was, thanks :)
<jab>I just got it set up and running upstairs. I can ssh into it...I need to set it up with a static IP address.
<jab> far, I've no idea how powerful it is. I'll get it serving my websites:,, etc...then I'll work on getting it to host my email...then I plan on getting it to run a instance.
<jab>maybe peertube at somepoint.
<nckx>projectmoon: When you said ‘splash/background’ above, you did mean the Guix logo, not the Coreboot GRUB, right?
<projectmoon>nckx: yes
<projectmoon>Gonna try adding that one line as described in the post
<projectmoon>Once a toddler who refuses to sleep succumbs to sheer exhaustion
<nckx>jab: Well, the CPU's a full generation newer than my laptop's ☺ It'll be more than adequate for that. I ran a Guix build server on similar hardware for a while, though I'd have killed for 30G of RAM.
<nckx>I don't remember how I phrased my question but I meant electrical power (€/$), not computing power.
<nckx>That's my main worry whenever I see ridiculously cheap powerful-for-the-time old hardware.
<nckx>It's usually at the far end of the tradeoff curve, especially now.
<lispmacs[work]>jumping in: I'd say a big question is to figure out what governor cpu frequencies are available for the CPU
<nckx>Very true! It had a shocking (positive) effect on one older box. Whatever you do, ignore the strange people on-line who say it's not for ‘servers’.
<nckx>I think they have problems.
<lispmacs[work]>and don't forget to take advantage of that, you have to set the run-time kernel governor parameter
<lispmacs[work]>or, boot time, I guess
<janneke>hmm, "herd start guix-daemon": failed to start; how do i get more info about that?
<civodul>janneke: hi! does /var/log/guix-daemon.log show anything useful?
<janneke>civodul: no, i don't think so
<boeg>I'm just using %base-services - how do I get dbus running? I've tried running some apps that needs dbus, and it doesnt work. I do have the dbus-service as part of my services
*janneke runs the daemon by hand now
*janneke tries pull, system reconfigure
<atuin>leoprikler: thanks, that was indeed fast :D
<janneke>no problems building a childhurd, btw; just no substitutes apparently
<civodul>ah, we should fix that
<civodul>janneke: you can always try "strace -f -o /tmp/log -p 1 & sudo herd restart guix-daemon"
<civodul>(faster your seat belt)
<janneke>civodul: ah right! i'll try that!
<civodul>roptat: i have a tiny change that halves the number of syscalls made by "guix help"
<civodul>but thing is "guix help" works by reading the (guix scripts ...) source files
<civodul>the rationale was that it was (presumably) cheaper than loading all of them:
<janneke>14288 write(2, ";;; Failed to autoload fork+exec"..., 64) = 64
<janneke>14288 write(2, ";;; In procedure resolve-interfa"..., 96) = 96
<civodul>but i guess that remains expensive on low-end hardware :-/
<civodul>janneke: what version of the Shepherd is PID 1?
<janneke>civodul: uptime 215 days
<jab>roptat: your mail configuration is breathtakingly beautiful. :)
<jab>I'm tots going it steal your dkim bits. :)
<janneke>civodul: /gnu/store/277md04f98aaacqlcwpwd9xrw3skb4za-shepherd-0.8.0
<civodul>janneke: hmm it might be the reason then, though i don't see anything obvious
<projectmoon>Is the mirror slow?
<janneke>civodul: thanks, /me goes to reconfigure and possibly reboot
<projectmoon>installation has crashed twice now because of some CI download failure, and then i have to start it all over again
<nckx>projectmoon: Which mirror?
<projectmoon>not sure, the CI one? o_O
<nckx>It's not a mirror. And yes, unfortunately, Guix networking is still not what it should be (maybe civodul would like to see the details, I don't know 😉).
<projectmoon>might be the ath9k card instead
<raghavgururajan>nckx: Which channel? I am bored.
<nckx>Still, having to restart the installation is not an acceptable thing to throw at users, and my apologies for that projectmoon.
<projectmoon>now database disk image is malformed
<nckx>raghavgururajan: It's a channel you can no longer join, and it's probably for the best. You're not missing anything.
<raghavgururajan>nckx: Cool!
<projectmoon>ok, now downloading again... while sitting next to a router
<nckx>😃 Very cool (not).
<civodul>projectmoon: could you email with the details of download failures?
<projectmoon>i have a mesh network, and sometimes those tend to cause issues for certain wifi drivers
<civodul>make sure to say which version of guix-daemon is running
<projectmoon>civodul: if it happens again, yes
<projectmoon>assuming i can actually get that information
<projectmoon>it's in the middle of installation attempt #8 or something
<nckx>sneek: later tell mothacehe: Would it be hard to implement a ‘retry’ button in the installer? It could come with a nice disclaimer that success (or even sane state) can't be guaranteed, but anything is better than having to restart from scratch.
<projectmoon>there is a retry mechanism, but it derps out
<projectmoon>it gives you the option to resume from where ever, including editing of config
<projectmoon>but if you try to run it after that, it blows up with /mnt missing or sometihng
<projectmoon>not sure if that applies to only encrypted partitions or not
<boeg>i'm trying to run swaylock but it says it needs to be setuid. What is a a good guix'y solution to this?
<boeg>ah sorry, found manual page right after asking
<projectmoon>ok, boot attempt #X, this time with i915 in initrd
<nckx>I expect it to be able to print the true error now.
<projectmoon>no error, only greatness
<projectmoon>except for entering the decryption password twice because of i guess missing key material
<nckx>Yes, that's expected.
<nckx>And the only supported mode so far.
<projectmoon>i can live with two passwords
<nckx>I'm guessing you could have typed you passphrase blindly and hit return and booted without i915? Because I booted without it in the initrd for a while, and it just meant my screen was blank for longer. It never failed. Interesting regression if not.
<projectmoon>no idea
<projectmoon>but, it might be very useful for this to be documented somewhere
<projectmoon>aside from one random guy's purism forum post
<nckx>The installer should add it as default if it thinks it might be needed, that's the point of an installer. It could add a comment noting that it's an educated guess, so the brave can break^Wtweak their system if they so desire.
<projectmoon>yes, so i guess it's better reported as an issue?
<projectmoon>that the i915 needs to be in initrd-modules when: A) librem 14, B) encrypted disk
<nckx>Yes. I was drafting a report, but it would be much better if you would have the time to do so. :)
<nckx>Since you'll be CC'd and can give further details if needed.
<projectmoon>how do i make bug reports?
<nckx>Send a mail to bug-guix at
<projectmoon>via mailing list? or is it possible to use a web UI on the issue tracker
<nckx>Nope, sorry.
<projectmoon>3447 new commits, ezpz
<nckx>It should be possible to detect that i915 is in use (or at least loaded).
<nckx>And thank you :)
<maximed>sneek: later tell mothacehe: I sent a v2 <>
<sneek>Will do.
<projectmoon>nckx: well I'm not the one who discovered it. Some guy on the purism forum did. I just tried his solution
<maximed>Next step, teach "guix style" to automatically fix the issue in trivial cases?
<nckx>It didn't show up in my local search for i915 but does via the Web UI.
<nckx>So it has been reported, it just needs to be fixed :-/
<nckx>lol I commented on it. I truly am demented.
<maximed>"./pre-inst-env guix fix package-definition && ./etc/committer.scm && git send-email ..." (-:
*nckx remembers nothing.
<drakonis>i have two patches to send now
<drakonis>all i need now is to set up my email infra to send patches
<projectmoon>nckx: lol
<projectmoon>It is a bit... Specific of an issue
<nckx>I'll boot a Guix installer on this machine to find the most reliable indicator of ‘needs i915’, but it'll have to wait for obvious reasons. Unless there's an emulator that emulates it?
<projectmoon>nckx: what module did you put librem-ec-acpi-linux-module into?
<nckx>(gnu packages linux).
<nckx>If it's not there, you're not using the most recent Guix.
<projectmoon>well i did a guix pull
<projectmoon>do i need to reconfigure system first
<jab>does anyone know where the dkimproxy-out-service-type service definition is found?
<jab>I see an example of it's use found here:
<jab>but I don't know where the service-type definition is...
<nckx>projectmoon: First, you should make sure that ‘command -v guix’ returns ~/.config/guix/current/bin/guix. And that you're reconfiguring with ‘sudo guix’, not logged in as root.
<jab>nevermind I found it:
<projectmoon>nckx: it's pointing at /run/current at the moment. i'm going to reconfigure then reboot and make sure the profile and stuff is pointing in the right place
<raghavgururajan>nckx: I fucked up. I wanted to push e61874a5983c4fcb39b33248d044f22257e2f189, but 1cc89f08b816f56e1bca25340e945b1cbb34f05d and 3fdb2d679259f5d1541240dd4e9cedda17040bf2 also got pushed, since I forgot to remove them in my local tree. Is it possible to remove those extra commits? Sorry.
<nckx>projectmoon: Both overkill, but can't hurt either.
<nckx>raghavgururajan: Simply ‘git revert’ them and push both reverts.
<raghavgururajan>nckx: Okay, thanks.
<nckx>The mild shame you may feel at your mistake being immortalised is punishment enough. 😉 Git is good at that.
<nckx>I mean, *really try* not fuck up, and don't get used to it, but: everyone does.
<nckx>It's only when someone does so frequently or doesn't seem to care that it becomes a problem.