<leoprikler>I imagine someone will someday write a systemd service type and rewrite operating-system to use it <dstolfa>... if by then we don't have systemd++ <Telc[m]>guix is awesome with what it does do <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 <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]>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 <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>very few things are specified and transmitted out of bound <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]>guix choosing to regenerate upstream systemd files for every service it ships <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 <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 <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]>so the edsl is used generically to produce text conf files or records for shepherd depending <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 <dstolfa>guix does, and i don't think it's in /etc <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]>what is the method for the ipc? is it like calling wrapped c or guilesomething? <dstolfa>Telc[m]: skimming through shepherd code, it seems to be via sockets in guile <dstolfa>but that's all i'm doing, skimming :) <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]>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 <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 <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>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` <drakonis>Telc[m]: it doesnt use systemd and the bit about changes to services requiring restarting everything isnt quite right <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? <ixmpp>weechat needs the SSL_CERT_DIR variable set <ixmpp>is it convention in guix to wrap it to provide 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 <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>i'm confused how i've ended up with a shell without that variable then <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 <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>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>leoprikler: so i just edited grub.cfg manually to boot into the other OS <wirez>does guix have support for upside down monitors? <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>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 <ixmpp>I know, thats why i wondered how to get around that <ixmpp>But no worry, seems gcc --print-libgcc-file-name does it <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 ^s.so$ /gnu <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>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) <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 <bricewge>Is there a bug report tracking package collision and forcing precendence? I can't find it ***Kimapr7 is now known as Kimapr
<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>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 <mfg>so (make-gcc-toolchain gcc-final musl) should work? <civodul>i'm still getting report about substitute connection timeouts, "corrupt input", and the likes :-/ <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>and i pavucontrol running and working which uses pulseaudio <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>(You'll get used to it. I promise.) *nckx forgot to say hi all. Hi all! <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
***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? <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 <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 paste.debian.net 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>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… <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>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. <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. <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 <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 <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. <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>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. <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 <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. <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>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? <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. <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 <sneek>Welcome back abcdw, you have 1 message! <sneek>abcdw, ixmpp says: hey, any plans to sort out gtk themes, 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. <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 <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 <dstolfa>tricon: i think my precision 5550 sends scancodes <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 <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. ***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" :/ <dstolfa>i was about to say... wow that's long <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 ? <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? <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 ? <luis-felipe>tissevert: the requirements directory has guix manifest, so you could pass it to guix environment, for example. <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 <efraim>having just meesed with it, is the time different beween 'guix help' and 'guix --help' <roptat>efraim, looks very similar to me <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 <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>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 <abcdw>civodul: Did a dirty trick: 3>&2 2>&1 1>&3- | grep -v ";;;" <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 <civodul>but for "guix help", we could also prolly reduce the amount of work done <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 <zimoun>What is the status of the core-update merge? And v1.4 in September, is it still realistic? <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>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 ;-)) <danialbehzadi[m]>I know the difference between `input` and `native-input`. But couldn't figure out the `propagated-input`. <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. <roptat>inputs that are referenced from the package are otherwise only added to the store, but not to the profile <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 <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 <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 <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 <leoprikler>apapsch is it 49254~49258? I already merged them <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. <xnnnx>Is there techical guide on making package definition ? For what to look for not and those that should be prosent. <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. <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 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>grub boots up fine and has the guix boot entry, but after selectin git, grub just hangs at an empty guix screen <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 <Aurora_v_kosmose>Does Guix support whatever hardware is used for the graphics display by default? <projectmoon>do i perhaps need to add some graphics drivers to the system config? ***Kimapr6 is now known as Kimapr
<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? <nckx>‘nosplash’ doesn't do anything. <projectmoon>when starting the boot, the grub UI disappears, leaving the background <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 <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>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>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 :) <apapsch>Aurora_v_kosmose: how about the php engine? :-P <Aurora_v_kosmose>Well that or hacking Guile into the engine and exposing it the necessary Guile objects. <apapsch>before I attach the behemoth I'd rather take the guile speed bump <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. <boeg>is tor browser available in guix? <roptat>it's very hard to build, but if you manage to, I don't think there's any reason to reject it <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>(and man-db for the manual page reader) <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. <boeg>nckx: care to share how you did it? ***apteryx_ is now known as apteryx
<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 <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? <Aurora_v_kosmose>projectmoon: Normally a Guix executable should exist in the normal paths that then sets up stuff. <roptat>projectmoon, maybe /run/current-system/bin/guix? <roptat>/run/current-system/profile/bin/guix <roptat>you'll need to run the daemon too if you want to work on packages <leoprikler>does anyone know why my local guix checkout reports 79% on all LOAD and GUILEC tasks? <roptat>/var/guix/profiles/system/profile/bin/guix <roptat>since you're in a chroot, the normal boot process didn't occur, so it's normal that some stuff are missing <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 <roptat>you'll need to mount some additional file systems to get it to work <roptat>replace $LFS with your chroot mount point <projectmoon>But I guess I need to start the guix daemon or something <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. <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>That's why they're chrooting. <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. <nckx>There won't be any if it never booted a good way into user space. <nckx>Is there anything in /var/log? <projectmoon>Can I change the kernel in config. Scm during the install? <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. <projectmoon>Guess I'll just try installing once more with an older kernel <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? <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. <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 <atuin>ok, so it's kind of a bug then :) thanks <nckx>I can't see which advantages could be indended ☺ <leoprikler>the advantage is obviously O(n) instead of O(n^2) in the profile hook ;D <atuin>yes I can, let try to reproduce with few packages <roptat>what's the policy for updating the guix package? <atuin>leoprikler: `guix environment --ad-hoc emacs emacs-guix` <atuin>that produces several duplicates :D <atuin>seems emacs-guix is good producing duplicates <roptat>I mean guix in (gnu packages package-management) *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 <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>it was enabled, top showed that it was used, but not by guile <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 <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. <nckx>Also, use (gnu packages linux). <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. <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 <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. <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>There's a post in there that's similar to my problem <nckx>Oh, wait, you're using Heads? <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. <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>so...so far, I've no idea how powerful it is. I'll get it serving my websites: gnucode.me, propernaming.org, etc...then I'll work on getting it to host my email...then I plan on getting it to run a libre.fm 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>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 <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? <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>janneke: you can always try "strace -f -o /tmp/log -p 1 & sudo herd restart guix-daemon" <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 <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? <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 <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? <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 😉). <nckx>Still, having to restart the installation is not an acceptable thing to throw at users, and my apologies for that projectmoon. <nckx>raghavgururajan: It's a channel you can no longer join, and it's probably for the best. You're not missing anything. <projectmoon>ok, now downloading again... while sitting next to a router <civodul>projectmoon: could you email bug-guix@gnu.org 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>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>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 <nckx>I expect it to be able to print the true error now. <projectmoon>except for entering the decryption password twice because of i guess missing key material <nckx>And the only supported mode so far. <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>but, it might be very useful for this to be documented somewhere <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>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. <nckx>Send a mail to bug-guix at gnu.org. <projectmoon>via mailing list? or is it possible to use a web UI on the issue tracker <nckx>It should be possible to detect that i915 is in use (or at least loaded). <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 ..." (-: <drakonis>all i need now is to set up my email infra to send patches <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>If it's not there, you're not using the most recent Guix. <jab>does anyone know where the dkimproxy-out-service-type service definition is found? <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. <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.