<ng0>if anyone updates gnunet before I come out of my guix semi-hiatus: https://git.gnunet.org/gnunet.git/tree/README#n192 i just spend a bit of reasoning with portability to come to the conclusion that this is the best way to do it and no one will notice anyway because the old way was not working as intended.
***modula is now known as defaultxr
*nckx becomes the official mascot of ‘don't push right before you go to bed!’
<nckx>I was a Nixer for a time (year or two). I'd heard of Guix before (Ludovic popped up once or twice on github.com/nixos, IIRC), but I didn't quite ‘get’ it. I liked the GNU part of it, though: NixOS's ‘open-source’ ‘pragmatism’ wasn't my dream but (to echo your sentiment above) I couldn't tear myself away. However, the merging of yet another blob finally made me download this Guix thing. Oh, I said, this is an actual GNU project. Why the he
<nckx>ll am I not using this. So I learnt Scheme. In the Guix installer. Without Internet. By typing stuff into zile until the errors went away. 14 hours of fun later, I was in love.
<dekaidle>I'm running en_GB.utf8. I just reinstalled so I'm running the defaults from 1.0.1. Last time I did a reconfigure, I broke my system, guix wouldn't run (had to manually find a working binary in the store) and every program would segfault
<dekaidle>so I reinstalled. Haven't tried reconfigure yet
<dekaidle>didn't look too much into it, which I probably should have...
<nckx>There's definitely room for improvement here. No question.
<dekaidle>as long as there's a reason. Good to hear I'm not the only one experiencing issues though, thanks for clarifying that for me. Otherwise I'd probably still be pulling my hair wondering what I broke this time.
<nckx>dekaidle: You can try building dub manually: guix environment dub -- true && guix build --no-substitutes dub
<nckx>(That's my ugly hack for ‘don't build the build dependencies from scratch, only dub itself’).
<dekaidle>nckx: alright, thanks a lot. Will try once I finish upgrading the rest of my packages.
<nckx>I'm running it now, I'll let you know if it's a dead end (it's currently building phobos; no substitutes for that).
<mfzap>guix pull seems to want to compile a lot in the past couple days - are the substitute creating servers down?
<apteryx>nckx: re bluetooth; I'm still wondering what's the problem with your setup.
<nckx>apteryx: Oh, thanks, but don't wonder too much. Maybe it's ‘expected’ (either with my adapter or this magical apple mouse or BT in general). Maybe it's some power saving mode. Maybe the future just sucks.
<apteryx>I don't run any fancy DE, and as long as I've paired a device (manually through bluetoothctl), it'll stay connected and be available at boot when I have auto-enable? set to #t.
<apteryx>ugh, apple magical mouse. I've long donated the one I happened to have -- I couldn't stand the pointer jumping around any time I'd touch it (forgot the exact details, but it quite annoying to use).
<leoprikler>btw. why is guix always so eager to update substitutes?
<leoprikler>can you not do that once at the start of the command and then call it a day?
<roptat>leoprikler, that's because we update substitutes as needed
<roptat>we only fetch substitutes for what needs to be built, but if one is missing, then we need substitutes for build dependencies of that thing, and we update those
<leoprikler>but can "as needed" not be computed at the start of "guix package ..."?
<roptat>if we updated substitutes for everything at once, it would take a few minutes I think, since that's what guix weather needs for getting information on the availability of substitutes for the whole distro
<shrdlu68>I'm getting this trying to reconfigure: "guix system: error: python-pep8-stdlib-tokenize-compat.patch: patch not found"
<roptat>no, because that depends on availability of substitutes: if one is missing, it adds more substitutes to fetch
<roptat>although I agree we could re-use the same line instead of printing multiple lines
<roptat>weird, I just pulled and there's even a substitute on the build farm...
<roptat>are you sure you're using the guix you've just pulled?
<jgart>Hello, I'm running into this issue on my guix server with tmate: https://github.com/tmate-io/tmate/issues/154 How would I got about downgrading libssh to version 0.8.7? I see when running guix edit that this is the current package definition for tmate:
<shrdlu68>roptat: It finally worked, I could swear I've done this before and it didn't work.
<roptat>jgart, I'm not sure how you use tmate. If you install it on a profile, you can use "guix install tmate --with-commit=libssh=libssh-0.8.7"
<roptat>if you want to fix guix itself, you'll need a package for libssh 0.8.7, and you'll name it libssh-0.8.7. Then, tmate would use that package instead of libssh
<jgart>roptat ohh ok that sounds like that would work. Let me try it. I'm not sure what is the latest status on newer versions of libssh breaking tmate. I just read from the github issues that version 0.8.7 doesn't give me the lost server error. I will look further into it now. I'm just trying to get tmate to atleast run so I can screenshare
<shrdlu68>What package contains "dig" from bind-utils?
<grumbel>When installing third party packages via "guix package -f custom_package.scm" I get a lot of "guix package: warning: package 'custom_package' no longer exists" and in turn conflicts do the different library versions. Is there any easy way to fix that and force rebuilding of those packages with the new libraries without having to find the original .scm?
<bdju>it seems that the crystal language is not packaged!
<efraim>Parra: thanks. Sometimes I need the obvious suggestion :) I figured it was complaining about port 80 in the container but I've since realized it was port 80 inside and outside the container. Port 8080 did fix that
<ng0>raghavgururajan: yes, when you prepare enough for pain points to encounter
<ng0>I'd advise to do an experiment first for a while and then see if it's for you. back then we encountered enough to not make it usable for us
<civodul>raghavgururajan: the only blocker for "production servers" would be a missing feature for your use case
<ng0>civodul: for us the killer was shepherd and occasional development inside guix where sshd would not work, and the inability (caused by the way shepherd is written iirc) to have some webservices defined we needed. now we're just using another Linux-based system with guix
<ng0>that was a ~7 months period in 2018, so it might as well be better now in some aspects
<ng0>hm, i never pushed the buildbot files your way right? i mean, is there a buildbot (minus service) in guix? if not, i might as well setup guix elsewhere and start pushing the packages i have lined up
<apteryx>nckx: re bluetooth disconnection, that's definitly abnormal (I have apple wireless keyboard and used to have magic mouse, and both worked OK with Guix System and would reconnect automatically if paired).
<gnutec>roptat, I use "guix pull" and "sudo guix system reconfigure /etc/config.scm" but he didn't finish, some problem with google router maybe.
<roptat>gnutec, do you mean it's still running, or was there an error?
<roptat>when you run guix pull, it updates the set of available packages, but that also means the build farm didn't have much time to build everything, so substitutes might not be available yet
<apteryx>nckx: anything in /var/log/messages when you turn back on your device?
<gnutec>roptat, understand! Thank you! I'll try again later.
<refpga>Hi, how does one execute scripts at startup in GuixSD?
<raghavgururajan>civodul Anyway, other than features, I was concerned about stability. Like, when the guix system is updated every week, will there be an issue of system not booting or some services breaking? I understand that one can --roll-back or --switch-generation. But it is going to be consumption of extra time; when; the situation happens often.
<raghavgururajan>civodul I think my concerns and fear are steming from poor understanding of how packages in guix in updates, how branches work etc. I should review the manual.
<dongcarl>question for y'all... If I have a package that I've already built once before... so `guix build` will just return its path, but I wanna inspect it like how I usually do, by `Ctrl-C`ing in the middle of a build and going to the directory in `/tmp`, how might I do that?
<dongcarl>civodul: Yeah, the error messages are identical... Yes, config.log coming right up!
<nckx>raghavgururajan: We only ship supported kernels. 5.2 was recently removed for that reason, everything else is LTS. Your concerns about branches are justified: ‘master’ isn't ‘stable‘, it just happens to work most of the time.
<dongcarl>I've actually narrowed it down to what line in `configure.ac` is causing this mess...
<dongcarl>But I just don't know how to fix it and why it's causing it
<dongcarl>It's L1321 in `guix-build-gcc-glibc-2.29-9.2.0.drv-2/gcc-9.2.0/gcc/configure.ac`
<dongcarl>It adds 2 `-I`'s, after which the configure log goes haywire
<dongcarl>grep for `getrlimit` and you'll see that the second time it's checked (right after L1321) is where it goes bad
<nckx>apteryx: Sure, but maybe I was unclear. There's no ‘split brain’ problem on my laptop: once the kernel sees the device, so does the rest of the system, and the mouse works. So once dmesg prints something all is fine. http://paste.debian.net/plain/1109979
<civodul>dongcarl: looks like we're missing the bit that determined that vasprintf is not declared
<civodul>could you check the other config.log files you have?
<civodul>which leads to conflicting declarations for vasprintf, which leads to 'basename' considered as undeclared
<nckx>civodul: The upstream hash for psmisc-23.2.tar.xz has changed, all mirrors have the new hash, and I don't have an ‘old’ copy myself. Nor does ci.guix. Any chance that a build node would have it, or is that not how things work?
<nckx>raghavgururajan: /var/log/messages has some of them. Some are just printed to the console and never logged (yes…). If this is about panic messages, though: they are never saved, the system will not write to disc if it's that sick. It has no way of knowing its worldview is in any way correct, so it could corrupt anything.
<nckx>raghavgururajan: I use the awesome and unloved pstore facility to log panics to the firmware nvram (flash), which can be mounted as a file system.
<nckx>However, it has some rough edges (it can cause some UEFI implementations to refuse to boot until you clear it if it gets too full) and I'm pretty sure it's disabled in the Guix System kernels.
<dongcarl>civodul: So, the top level configure doesn't check for vasprintf at all... It seems that each submodule checks vasprintf itself... And every other module finds vasprintf, except for the gcc submodule...
<dongcarl>I also grepped all the config.logs for the strings "has a different exception specifier" and "ambiguating new declaration", and only the gcc/config.log has that... I believe that the declaration error in gcc is the root of the problem.
<dongcarl>Note that in gcc/configure, some things get checked twice, like "getrlimit", and the first time is fine, whereas the second time it fails... Which is what leads me to L1321 of `gcc/configure.ac`, where failures start happening
<gnutec>nckx: The system always told me to do something like " install glibc-utf8-locales... export". I did, reboot the system, but still send this messenger. When I command "guix package -l", it is there.
<mbakke>derp, there is no Makefile at all before the 'build' phase, of course...
<nckx>gnutec: Could you report the AisleRiot bug to firstname.lastname@example.org? AFAICT it's not a bug with the aisleriot per se.
<gnutec>nckx: What about the touchpad? Do you haved? I can't tap to click, understand?
<nckx>gnutec: I don't have time to walk you through, but you can probably use change a setting in your xorg.conf like I do here (‘Tapping’). <http://paste.debian.net/plain/1110355> However: I use libinput, don't know what you use; and I use the TrackPoint and disable the touchpad, so make sure you put it in your touchpad section.