IRC channel logs


back to list of logs

<civodul>singpolyma: yes; you can already experiment with that using "guix environment", it's just perhaps less convenient
<singpolyma>guix environment -f thing.scm isn't more convenient than guix environment -L. mypkg though which is what led me to the latter
<singpolyma>But yes, I could start to try to set up for what will be convenient with guix shell and test with guix environment
<mekeor>i love this package declaration for the suckless simple terminal with gruvbox theme and scrollback-feature: <>. thank you, guix!
<nckx>mekeor: Nice!
<nckx>And yes, Hack is the correct font.
<mekeor>i hope i did it correctly, using propagated-inputs for hack
*mekeor uses hack since years *.*
*dstolfa is a fantasque sans mono kind of person
<nckx>I can rail against propagation sometimes but it's appropriate here, mekeor.
<nckx>Well, the world would be a boring place if we all used the right font.
*dstolfa can imagine a world where everyone uses fantasque sans mono and comic sans... that would be a nice world for my eyes
<singpolyma>Means you won't be able to run st without activating a profile
<dstolfa>i don't like st :)
<nckx>dstolfa: I don't have the DPI for Fantasque Sans Mono to be honest.
<singpolyma>I just mean the propagation
<dstolfa>nckx: sad times :(
<nckx>‘guix install st’ or (packages (list st …)) or a manifest seems like the expected way this will be used.
<dstolfa>nckx: it is a very pleasant font on the eyes... i've spent years getting my configuration just right for my eyes at least. i've settled on black background, orange foreground, beige-ish comments and fantasque sans mono as the font
<nckx>I can have a touchy screen or a pixelful screen but not both, I checked.
<nckx>dstolfa: In all seriousness it does look nice.
<dstolfa>nckx: i feel that most of the commonly used mono fonts look good and it just comes down to preference :D
<nckx>A bit… playful for my taste, but then the name's right there on the tin.
<dstolfa>heh, fantasque sans mono feels a bit boring for me because my previous font was
<dstolfa>but it was a little bit annoying because some symbols just looked off, notably >, < and ?
<dstolfa>nckx: i'm weird like that... :P
<nckx>I just recursively guix import go'd a thing and it's over 12,000 lines.
<nckx>OTOH, that's a lot of lines for Guix to successfully produce without a single backtrace, well done Guix.
<apteryx>dstolfa: I've used the 'font-hack' package since I've been doing Guix; haven't bothered finding something better, which probably means it's good :-)
***jpoiret5 is now known as jpoiret
***herlocksholmes9 is now known as herlocksholmes
***yang is now known as Guest428
<Minall>Hello Guix Community!... Any official installs on docker and GNS3?
<Minall>drakonis For networking arquitectures and studying
<apteryx>raghavgururajan: not sure if you knew that trick; but adding libxml2 as a native-inputs sets XML_CATALOG_FILES and usually makes the docbook machinery happy (this is easier than adding custom patching phases to substitute the hard coded references)
<apteryx>sneek: last seen lfam
<apteryx>sneek: seen lfam
<sneek>lfam was last seen in #guix 6 days ago, saying: I'll be pushing it pretty soon.
<apteryx>weird, I can't seem to reproduce this python-keras failure on staging locally:
<dragestil>trying to install guix for the second time, getting substitute: updating substitutes from ''... 0.0%guix substitute: error: TLS error in procedure 'write_to_session_record_port': Error in the push function.
<dragestil>any ideas?
<dragestil>this is after doing things with /mnt (initializing, copying to, populating)
<apteryx>could the connection be flaky?
<apteryx>try using an ethernet cable if you have that option
<dragestil>yeah it is using an ethernet cable
<dragestil>more specifically i'm installing in a vm in a bridged network
<dragestil>had no problem installing trisquel with the same method
<dragestil> the same error message but not duing installation
<apteryx>I think there have been fixes since the last release in that area; you may want to grab an image tracking the latest code
<dragestil>ok, i was doing it with the 1.3 installation iso
<massn00b[m]>The system image cross compile fix seems to be working nicely
<dragestil>where can i find a newer iso?
<dragestil>got mine here
<apteryx>on, e.g.:
<apteryx>I'm not sure it'll resolve the issue, but perhaps worth trying if you get the error every time
<dragestil>not loading under librejs :(
<apteryx>we should fix that! i'll open an issue.
<dragestil>cool thanks
<dragestil>i'll try the latest iso image (is it installation image?)
<dragestil>why does guix require a root password btw
<dragestil>debian / ubuntu installations can skip root account
<apteryx>perhaps just something that could be changed in the installer; I can't think of a reason why it should be required (the user could be made sudoer instead), unless I'm overseeing somethnig.
<dragestil>ah, a second try of the installation worked
<dragestil>do people run ansible playbooks on guix hosts?
<apteryx>dragestil: it happened
<dragestil>what happened
<apteryx>dragestil: eh, sorry for being vague, I meant yes, I sometimes use Ansible on Guix (not to provision Guix machines though, for that I'd use 'guix deploy')
<dragestil>i tried my playbook to set up users, ssh keys and sudo, but it complained about not finding python3. i'm guessing binaries are not in the usual paths
<dragestil>also ssh into a guix host seems to forward $TERM environment variable
<dragestil>i'll try another time
<dragestil>maybe with guix deploy
<dragestil>btw the initial nonroot user is indeed in sudo group, so root password should be optional
<apteryx>if you'd like to report an issue for this, feel free to mail with an appropriate title and explaining the feature request :-)
<dragestil>ok thanks. i'll probably have to search the mailing list archive before doing that :)
<apteryx>I've reported the LibreJS issue for Cuirass (the CI) here:
<dragestil>awesome, thanks a lot
<apteryx>np! thanks to you :-)
<char>Hello, I am wondering if anyone can help me. When I (successfuly) log into Xorg I get "oh no! something has gone wrong. a problem has occoured and the system cannot recover." taking up the whole screen. I have tried: relogging, upgrading packages, deleting /var/lib/gdm/*, using slim instead of gdm, removing my .config, .cache, and .local. I reboot after each thing I try.
<char>btw, I can log into Xorg as root just fine.
<drakonis>char: you have deleted the hidden files inside /var/lib/gdm/, right?
<drakonis>just to be sure
<drakonis>now back to sleeping
<char>I delted .config, .local, and .cache, but I wasn't sure about .esd_auth
<wehlutyk[m]>hello guix
<wehlutyk[m]>in the course of upgrading python-h2, I need pytest to use python-hypothesis-5.23 (instead of python-hypothesis-5.4)
<char>drakonis: it looks like it is realted to sound, so it probably isn't relevant.
<wehlutyk[m]>so I'm adding python-hypothesis-5.23 to the native-inputs of python-h2, as is done for python-bidict
<wehlutyk[m]>but pytest still logs `plugins: hypothesis-5.4.1` when building python-h2
<wehlutyk[m]>Here is my package definition, on guix just pulled this morning:... (full message at
<drakonis>you also need to update python-hypothesis to point to the package name
<drakonis>i really should sleep
<wehlutyk[m]>drakonis: you mean the text between double quotes? `("python-hypothesis-5.23" ,python-hypothesis-5.23)` gives me the same behaviour
<drakonis>do you have a package with the new version?
<wehlutyk[m]>python-hypothesis-5.23 exists and is used by python-bidict
<wehlutyk[m]>and the logs of python-bidict's build actually shows `plugins: hypothesis-5.23.0, benchmark-3.2.3, cov-2.8.1`, (from )
<drakonis>i should be going now tho
<drakonis>peace yalls
<wehlutyk[m]>drakonis: thanks, and bye :)
<PurpleSym[m]>wehlutyk: I’ve been running into the same issue yesterday. My guess is that python-hypothesis is propagated somewhere, maybe through a PYTHONPATH wrapper.
<PurpleSym[m]>(I tried to update `python-h2` as well.)
<PurpleSym[m]>Ah yes, the `pytest` wrapper contains an entry for python-hypothesis-5.4.1. Unfortunately `python-build-system` does not distinguish between inputs and native-inputs when wrapping binaries :(
***PurpleSym is now known as PurpleSym_
***PurpleSym[m] is now known as PurpleSym
<raghavgururajan>apteryx: Ah I see. Thanks!
<wehlutyk[m]>PurpleSym_: indeed, running "python -m pytest" instead changes the error (now I see that it needs function_scoped_fixture, which was introduced in hypothesis 5.49)
<PurpleSym>I still feel we have to fix the wrapping process. This has bitten me multiple times already.
<wehlutyk[m]>I would say yes to that, but I think it's quite a bit further than what I know of guix so far :)
<civodul>Hello Guix!
<efraim>I think I fixed building go-1.17 on core-updates for architectures not using go-1.4
<efraim>I guess I'll put in the note for when to switch back with go-1.17's native-inputs, for when it's safe to switch back to gccgo
***Guest428 is now known as yang
<ennoausberlin>Hi. Does anyone uses Tensorflow > 1.9 with GUIX. Is there a chance to run it in a container or any other solution?
<civodul>ennoausberlin: hi! it's currently not packaged in Guix proper, due to Bazel not being bootstrappable
<civodul>i don't know of any "quick'n'dirty" packages either
<civodul>roptat: hi! the website fails to build since last week with: Throw to key `parser-error' with args `(#f "Unknown command" urefhttps)'.
<civodul>i don't see where that comes from, presumably related to the translation update?
<ennoausberlin>civodul: I read about the difficulties to package it, but I wonder if still nobody did this. My skill set is not good enough, though. There are efforts to use guix in a hpc environment, but unfortunately it is not ML related
<civodul>well, there are ML packaging efforts as part of Guix-HPC
<civodul>but yeah, there's certainly much more to be done
<ennoausberlin>civodul: Yes. I visit the site frequently for infos, but no luck yet. I would start a bountysource and offer some private money to get it done, but I heard it is really time consuming. Maybe a student steps in
<civodul>ennoausberlin: yeah, i guess that's something you could try
<ennoausberlin>civodul: I will set up something when I am at home.
<mekeor[m]>dstolfa: fantasque sans mono also looks nice :)
<brendyn>I think lmdb's pkgconfig file is inconsistent with other distributions. it is usually called lmdb.pc but ours is liblmdb.pc. i notice an warning from it not being found due to that building appstream
<wigust>hi guix
<liltechdude>Hello! Does Guix have something like developer documentation or high-level description of the concept?
<liltechdude>I know about nix's author paper, but may be something else?
<nckx>liltechdude: The first & third link here are similar to that one:
<nckx>I think. Been years since I've read either.
<nckx>But if anything's missing or hidden in some obscure paper it should probably go in the manual and not in another obscure paper, blog post, … ☺
<ruffni>what the best resource explaining the relationships on hex0, hex1, hex2, M1, mescc-tools and GNU Mes?
<sneek>Welcome back ruffni, you have 1 message!
<sneek>ruffni, RhodiumToad says: I put my version up at
<ruffni>wait what, sneek works on both #guile and #guix?
<nckx>Sneek is bicoastal.
<sneek>So noted.
<robin>hmm, anki managed to retain a reference to xdg-utils (for xdg-open'ing urls) that was, i assume, gc'd. wonder how that happened
<nckx>ruffni``: Might want to ask in #bootstrappable as well.
<robin>s/anki/qt/ probably (considering that i just installed anki like an hour ago)
<nckx>robin: Because it's not a reference as far as Guix is concerned: see ‘guix size anki’. No xdg-utils. If Anki/Qt/someone's mother *is* keeping a reference to it, it's not in a trivial bytestring form that Guix can sniff, breaking its reference scanner, and hence GC and grafting. Not good.
<robin>yeah i kind of assumed it was via qt or something
<nckx>This can happen when package install compressed binaries (.jars, hence why we disable compression), exotic GCC SIMD string optimisations (which we also disable), UCS-32 strings (which I'm not sure we handle yet), etc.
<nckx>Seems likely.
<nckx>Let's grep the closure for "xdg-open"…
<robin>bug#49460 might be related
<nckx>Seems extremely likely.
<robin>"Some programmes have a bug where they save absolute file names instead of looking in $PATH every time. That should be fixed upstream."
<nckx>Hm, no /xdg-open in there.
<nckx>robin: That's me ☺
*robin duly greps ~/.cache etc.
<robin>oh lol, so it is :)
<robin>hm, no hits for the hash in .local or .cache (grepping for the ascii/utf8 string)
<nckx>That was just a guess. I mean, it's happened before, but an educated guess nonetheless.
<nckx>Same here…
<nckx>I'm not really sure where to look though, I don't think I use anything Qt.
<nckx>robin: Have you tried rebooting?
<nckx>Not as a fix, but as a data point.
<mekeor[m]>yesterday i created a guix-package for my custom version of the simple terminal (st) from the suckless community. today i found out, suckless-folks are right-wing nazi-sympatisants from germany. they named a mail-server like hitlers head-quarter and do torchlight marches like nazis did. :( it's unfortunate that there is a guix-source file named after them: gnu packages suckless.
<robin>no, but i'll give it a shot
<nckx>yeah, so, suckless. Indeed.
<nckx>That's true.
<Guest59>How can I define user-level services with profiles? For example, I want an emacs profile that will automatically start an emacs server as soon as it is loaded.
<robin>nckx, no dice, i'll just add the info to the bug report for now
<nckx>Thanks robin.
<nckx>mekeor[m]: I never really understood why their stuff isn't just distributed amongst wm, xdisorg, etc. modules to begin with.
<nckx>And it contains stuff like scron that isn't from suckless at all.
<mekeor[m]>nckx: should we ask in the devel-mailng-list about those packages to be distributed accordingly?
<nckx>Go ahead! I thought it was ‘generally known’ that suckless was a bunch of dimwits (honestly: look at their code) but it's probably good to bring this up explicitly.
<mekeor[m]>nckx: is their code bad, too? i never really looked into it :D
<nckx>We can always rename it to (gnu packages suckles).
<mekeor[m]>nckx: i'll propose it soon
<mekeor[m]>nckx: haha
<nckx>It's just not great, and they think it is.
<mekeor[m]>nckx: which terminal emulator do you use? (:
<nckx>They tried to reinvent Unix minimalism, a concept as old as time, and still manage to underwhelm.
<nckx>mekeor[m]: Alacritty, after benchmarking catting a few megs into a few terminal emulators on a rainy afternoon. It was all very scientific.
<nckx>I wore goggles.
<nckx>(Anyway, suckless is a great example of how echo chambers are a bad idea both in politics and engineering, but it's not explicitly NaziSoft AFAIK? Is it? That would be a very different issue, and one with which we've already dealt.)
***xgqtd is now known as xgqt
<mekeor[m]>nckx: it's hard to know if they are nazis. the border between nazi and not-nazi is not sharp. and we don't have so much information about them.
<mekeor[m]>nckx: is alacritty faster than other terminal emulators with an Intel Graphics Media Accelerator X4500MHD graphics card?
<nckx>Oh, I don't mean the authors, but code/comments/output.
<nckx>Not that there's a sharp line if there home page links to or whatever, I understand, but if there are literally Nazi comments in guix build --source that's a big one.
<nckx>*their 😒
<mekeor[m]>nckx: ah well, then it was a rhetoric question, i guess
<Guest59>nckx: What would the implications of them openly being nazis be? Or having nazi comments? Will their packages be removed from the official Guix repo?
<mekeor[m]>nckx: did you spot such nazi comments in their code?
<nckx>Guest59: No.
<nckx>mekeor[m]: I didn't look.
<nckx>Thought you might've.
<nckx>mekeor[m]: Well, I don't own an Intel Graphics Media Accelerator X4500MHD (ThinkPad X200?) so I can't say. I have Intel HD 4000 graphics or whatever Ivybridge was called.
<Guest59>nckx: then what did you mean by "one with which we've already dealt"?
<nckx>Guest59: If your home page is a literal smörgåsbord of Nazi agitprop and general nutbattery we might, for example, not link to said homepage. Things like that. Giving specifics would rather defeat the purpose and I won't. But we won't remove packages just for that.
<nckx>I'd say figurative but I'm really hungry so deal with it.
<mekeor[m]>nckx: yes, x200 :D
<mekeor[m]>x200t, actually (:
*nckx 👋 fellow (X230)tabletoid high-five
<apteryx>someone has an idea of which of these pull guile@2.0.14 ? that's on core-updates-frozen:
<mekeor[m]>nckx: cool! yours has display-port and a touchpad :)
<apteryx>I guess that's for bootstrapping purposes
<mbakke>apteryx: are those grafted derivations? we still use guile@2.0 for grafts(!)
<nckx>I'm rather more enamoured by the 16 GiB of RAM and 4-core CPU 😛 I've disabled the touchpad in the BIOS, so you can have mine.
<nckx>mekeor[m]: ☝
<robin>"guix search anarchism" => nothing? how can we compete with debian lacking such critical packages?
<mekeor[m]>nckx: haha awesome. x230t could become my next laptop if i ever need one :)
<mekeor[m]>robin: agreed haha :D
<nckx>”The Anarchist FAQ is an excellent source of information regarding Anarchist (libertarian socialist) theory and practice. It covers all major topics, from the basics of Anarchism to very specific discussions of politics, social organization, and economics.”
<nckx>I was expecting a lame cowsay fork.
<nckx>OTOH, Debian seems to lack a SICP package, which is equally unacceptable.
<apteryx>mbakke: ah, I haven't built grafts, it could be this!
*apteryx retries with --no-grafts
<apteryx>mbakke: what is the reason? was 2.0.14 better for reproducibility?
<apteryx>mbakke: indeed, it was for grafts
<civodul>apteryx: Guile > 2.0, ahem, segfaults when running the grafting code
<civodul>see comment in (guix packages)
<apteryx>is this bug flagged on the Guile tracker?
<civodul>yeah, it was almost fixed a couple of times already, just not quite
<robin>(anarchism="An Anarchist FAQ" in debian; amusingly, when i was maybe 13 i mentioned i was interested in "libertarianism" (ugh) to a right-winger who suggested i look into anarchism, whereupon i installed the anarchism package, read it straight through, and shortly thereafter i was reading books like Zinn's _A People's History of the US_, serving as copresident of one of the earlier USian Gay-Straight Alliance student groups, attending the second US "Really
<robin>Really Free Market" after the first in miami, und so weiter...)
<robin>(he failed to specify that i should look into *right-wing* anarchism -- anarcho-capitalism, etc. -- to be clear)
<civodul>apteryx: what's the plan regarding the Big Rebuild on core-updates-somewhat-frozen?
<robin>nckx, now you have me trying to imagine what an anarchist cow would stereotypically look like
<nckx>robin: I made the same mistake (working out my own fledgling political theories as a child, hearing ‘libertarian’ in passing once, thinking ‘yeah that sounds about right’, embarrassment ensues). But apart from packaging anarchism for Guix (looking forward to that -patches@ thread) this is probably off-topic for #guix ☺ At least when people are discussing srs graft segfaults and it's not abandoned #guix Late Nite.
<apteryx>civodul: now that I've fixed the mess I had done on staging, I'd like to merge it in core-updates-frozen, to make sure they're aren't leftover bits
<civodul>apteryx: ah, good!
<robin>nckx, indeed, </off-topic-rambling>
<apteryx>civodul: I think staging could be merged already, if nobody has objections
<civodul>apteryx: go for it! :-)
<civodul>i haven't looked at it, really
<civodul>all i want is to merge core-updates-frozen :-)
<vivien>Has guix home been merged in core-updates-frozen?
<apteryx>civodul: hehe
<xd1le>mekeor[m]: thanks for mentioning this. I've generally been a fan of their software projects like dwm and dmenu for many years and had no idea. But yeah fuck that.
<xd1le>I mean politically I knew they were very anti-gpl but thought that was about it
<dstolfa>xd1le: you don't know the half of their politics, and it's probably best kept out of #guix
<dstolfa>it quickly devolves into literal nazism
<xd1le>dstolfa, yeah I was looking into all that just now.. and agreed
<nckx>I thought it was already there.
<civodul>vivien: it's in master; not sure if it's been merged into core-updates-frozen since
<dstolfa>nckx: i'd missed the discussion, but reading back, yes, yes it is literal nazisoft
<dstolfa>they've previously sent public emails from a "wolfsschanze" host
<wisp>While I agree, not sure how ontopic further suckless talk is... I guess let's not give them more attention than they deserve.
<vivien>xd1le, yeah, if you want to discuss it, maybe talk with them directly. If you’re invested in the software, they might listen to you
<wisp>Replacement for dmenu btw: rofi works well in my experience.
<bdju>what's the trick to adding ~/.local/bin to my PATH? I have some lines in my .profile that look like they should be doing it, but it's apparently not working
<dstolfa>wisp: yeah, i really like rofi's theming as well
<vivien>bdju, you need to log out and log in back again
<bdju>to be clear I did not just configure it, it's been in my .profile for months. I only just ran into something where it became clear it's [probably] never worked
<nckx>dstolfa: <NaziSoft> But, like — not to push some kind of ‘code is purely technical’ line that is clearly bullshit — is the Soft that Guix downloads & installs itself somehow Nazi (READMEs, comments, Triumph of the Will mkvs in the release tarball, …), or ‘just’ the community beyond it?
<bdju> here are the relevant lines. they're probably just wrong.
<bdju>I imagine I copied them from somewhere
<dstolfa>nckx: i'm not aware of any overt nazi references in suckless code itself, just the community behind it overtly following nazi ideology
<nckx>Not implying it's not our responsibility if the program spits out bug report addresses that lead straight to stormfront but just trying to understand how bad it is.
<nckx>dstolfa: Hmkay. Jeez.
<katco>hey all, is there anything weird going on right now? doing my weekly updates and 1 machine got a 502 against guix's savannah git repo, and another is crashing `guix publish` with "Warning: using insecure memory!\nFatal error: Cannot allocate memory\nSegmentation fault"
<dstolfa>i don't think it should be removed from guix as it's free software and i'm not aware of any nazi references anywhere, but since the discussion came up here
<nckx>To be clear nobody is advocating its removal and I don't expect it to come to that.
<nckx>We have a lot of freedom to modify it if it even comes to that 😉
<xd1le>vivien, yeah it's ok I don't think I use any of their stuff anymore anyway.
<mekeor[m]>dstolfa: i agree. let's just suggest to distribute the suckless package definitions across the according files
*mekeor[m] will use alacritty instead of st in future
<vivien>bdju, the PATH won’t be set unless /home/<you>/bin exists. Anyway, if the directory does not exist, it’s not a problem to add it to PATH, so you could just remove the if test and unconditionally set the PATH. Also, you have a double colon '::' inside, you might want to use a single one instead.
<nckx>katco: I've got a few 502s from Savannah cgit but they were transient (as in reproducible for ~5min but then stopped), I don't think that was more than the usual fritziness. ‘Insecure memory’ sounds like GPG…
<katco>nckx: ty for the data point. i'm trying to think of what would be going wrong with guix publish. hm.
<wisp>bdju: like vivien wrote, I suspect it's the :: since my config looks almost identical and works fine
<bdju>vivien: I have ~/bin and ~/.local/bin both
<katco>how is gpg involved?
<bdju>I'll try to fix that double colon. thanks for the tips
<nckx>katco: I don't know, ‘secure memory’ is just a thing used by crypto software. Could be SSH, but I don't see how that's involved here either…? The 502s were not today by the way, but the 10th. My plea in #savannah was apparently answered (thanks for reminding me to check):
<nckx><rwp> nckx, It looks like around the time you are reporting 502s that loggerhead for hg was getting swamped on the same server.
<nckx><rwp> nckx, It probably browned out the server and affected your use of cgit on the same server.
<nckx>Maybe still an issue…?
<nckx>katco: Could it be as simple as a legitimate OOM?
<katco>nckx: that was ephemeral for me too, and the pull eventually worked. the publish is not a legit OOM issue as far as i'm aware. i checked after the fact and i have something like 50GiB free
<bdju>okay, I removed the if/then bit, one of the colons, and I also saw I was sourcing /etc/profile before and after that bit, so I removed the second one. tested in another TTY and it seems to work now.
<bdju>thanks for the help vivien and wisp
<wisp>good to hear
<katco>this is very strange: `In web/server/http.scm: 118:27 2 (http-read #<<http-server> socket: #<input-output: sock…>) In unknown file: 1 (peek-char #<input-output: socket 16>) In ice-9/boot-9.scm: 1685:16 0 (raise-exception _ #:continuable? _) In procedure fport_read: Connection reset by peer`
<phodina[m]>Hi there, is there a way to specify to in a cargo-build-system to only build for Linux? The crate I wish to build has dependencies for mac and windows under cfg condtion which are pointless to package, but strangely they are pulled in and the build fails
<robin>for patches that shouldn't actually be committed (but might provoke discussion on different approaches, e.g. my having to add random code to the boot process for want of a hook), should i send them to -devel or -patches?
<nckx>Good one. I'd still say -patches, so we have a #, and since you probably think that this is a bug even if your fix isn't ideal, it seems worth a bug #.
*robin nods
<nckx>katco: Results from grepping the store so far only return 'using insecure memory!' in pinentry-* binaries…
<nckx>Is something prompting for a passphrase that should be using a key/agent/…? I don't have a better idea either.
*katco is very confused. also about this other error that popped up.
<katco>not that i'm aware of... i'm just invoking with `guix publish -u ${USER}`...
<katco>well `sudo guix publish -u "${USER}"` to be precise
<nckx>The http.scm error in itolation isn't suspicious, Guix networking being fragile is a known metabug. Of course, if random bits keep failing at an alarming rate, that's something else.
<katco>ok, well... i've confirmed this isn't a guix thing, it's a me thing, so i'll keep poking and see if i can't figure out what's going on. tysm nckx!
<nckx>Good luck, I'm intrigued ☺
<robin>i wish guix didn't abbreviate error messages (backtraces mostly) so aggressively. i used to know how to tell guile not to do so (maybe using debug-options?)
<nckx>Was it setting COLUMNS?
<nckx>The gotcha is that for backtraces produces by builds/the daemon, it has to be set in the daemon's environment.
*nckx AFK.
<robin>that might've been part of it, but there's also the "width" option, "Maximal width of backtrace." (it's entirely possible guile uses min(debug-width, $COLUMNS), i haven't checked in a long time)
<robin>that would be easy to control in CL ;) (not that i would want to write FORMAT strings involving pretty-printing directives...)
*apteryx attempts to merge staging into core-updates-frozen
<katco>nckx: as of yet, no further help needed, but i thought you'd be interested: this appears to be an issue with an interaction between my guix publisher machine and another specific machine on the network (ubuntu with guix package manager). another machine interacts just fine. very curious.
<nckx>warning: variable ‘success’ set but not used [-Wunused-but-set-variable]
<nckx>Could, maybe, not everything be a metaphor for my life today? SMH.
<nckx>robin: That's almost exactly what happens, but it's more like (or width (getenv "COLUMNS"))
<rovanion>nckx: me_irl
<nckx>katco: Oh boi…
<nckx>I wasn't quite wishing *that* level of spooky action at a distance on you.
*nckx hates network debugging.
<katco>i still have no working theory as to what's happening. networking issues are not at the top of my list though.
<katco>right now i'm suspicious that i've done something to bork my publisher's environment/store, although i don't know what that would have been
<nckx>I just meant debugging things with a network somewhere in the loop. I don't suspect network issues per se either.
<apteryx>nckx: you are not alone
<lilyp>phodina[m]: you can supply features, but if the windows stuff is pulled regardless you might want to rewrite the source
*nckx feels less alone.
<nckx>Judging by how outright giddy some folks are to whip out their wireshark I sometimes do.
<lilyp>Opening up Wireshark gives you an instant +50 INT
<lilyp>and it stacks with the +25% faster coding of using Night Mode
<katco>well, i have an ancient `guix-daemon` on the offending machine. 1.1, yikes!
<nckx>That thing belongs in a museum 🤠
<nckx>‘Wireshark’ is a great card name tho.
<katco>curiously, `root` on that machine is using the publish server just fine. it should be using the same daemon...
<katco>i'm so confused. i have no mental model here.
<katco>we'll see if updating the daemon makes the problem go away.
<nckx>But isn't root's guix on that machine equally ancient? Or do I misunderstand?
<nckx>Good plan.
<katco>nckx: i don't think i've ever gotten the workflow for guix on alien distros straight in my head. i set this one up long ago and have been doing `guix pull` and `guix package -u` from my user account. i think at times i was doing `sudo guix package -u`?
<nckx>This is compounded by the fact that I don't do foreign, but I think the default set-up is for the guix-daemon service (e.g., guix-daemon.service) to use root's pulled Guix, i.e. there's no separate system profile like on Guix Systems. So root's guix ought to be pulled once in a while to keep the daemon up to date.
<nckx>Back when I did foreign I'd edit guix-daemon.service to point to nckx's pulled guix to remove that requirement.
<katco>yeah i think i never got that into my head. i'm almost to all guix systems modulo my nas which will remain synology + guix
<nckx>It shouldn't matter much in practice since daemon development is glacial as it is, and tries to remain compatible when it does change, but perhaps you did stumble upon a real incompatibility.
<nckx>So it's good to update (pull) root's and restart guix-daemon just in case.
<katco>yeah. but 1.1! yikes. i don't know how it's been limping along.
<katco>updating the daemon seems to have prevented any further issues. so i think we can attribute this to some weird interaction between a v1.1 daemon and a v1.3 publisher/store
<apteryx>it'd be nice to have checks for this in guix offload; would save debugging nightmares
<apteryx>oh, that's just using substitutes
<katco>well i spoke too soon. `guix package -u` on the alien distro is now complaining about a "corrupt input while restoring archive from socket" despite an exception right before stating the publish server returned a 404 for a nar
<katco>gosh i don't know what's wrong. `guix package --substitute-urls='' -u` works, but is downloading a lot more packages. is my publisher serving a weird store somehow?
<foomar>Hello, does anyone have any idea about how to rewrite the `login-service' so that it does not require PAM? It's the last piece of my system that still requires it
<foomar>The same thing applies to the `openssh-service-type': it has a `#:use-pam' flag, but it extends the `pam-root-service' and installs the pam policy file regardless of the value of the flag.
<apteryx>katco: if you can, reboot the remote machine just for kicks
<katco>never a bad idea :)
***jonsger1 is now known as jonsger
<muzueufoia>Hi. I'm new to Guix. I tried a 1.3.0 install on i686. GDM displays a big "Oh no! Something has gone wrong." message on startup and /var/log/gdm/greeter.log contains "(.gnome-shell-real:373): Clutter-CRITICAL **: 08:46:33.471: Unable to initialize Clutter: Unable to initialize the Clutter backend: no available drivers found."
<muzueufoia>lspci says "Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)", in case that's relevant. I tried adding (specification->package "xf86-video-intel") to the packages list, but this didn't help.
<muzueufoia>I heard that a thing to try when GDM isn't working is to switch to slim. How do I do this? I tried adding (service slim-service-type) in the services list and changing %dekstop-services to (filter (lambda (x) (not (eq? 'gdm (service-type-name (service-kind x))))) %desktop-services), but then "guix system reconfigure" fails with "guix system: error: service 'xorg-server' provided more than once"
<roptat>hi muzueufoia
<roptat>the manual has a much shorter and probably better example for getting slim:
<roptat>(I think the reason it doesn't work is because the service type name is a string (maybe?) so it can't match with 'gdm, you'd need "gdm")
<muzueufoia>roptat: Thanks for the manual link! This sounds like just what I was looking for. (As for me trying to modify the service list without knowing about the modify-services function, I did verify in "guix repl" that my crummy filter expression does evaluate and does cause the list to shrink from 47 elements to 46, and that trying "gdm" instead of 'gdm throws a type error.)
<roptat>oh, ok
<roptat>then I was wrong :)
<rovanion>I want humbly promote the following patch given that it still applies:
<roptat>(car (cdr (car (cdr rest)))) is not a very guixy way to do it :)
<roptat>you should use match on rest instead
<roptat>(I get told that too often too :p)
<rovanion>roptat: Any suggestions on what I should do instead?
<rovanion>I'll make a note in the bug for future me.
<rovanion>I'm too tired. What does "match on rest" mean?
<rovanion>I get that it's pattern matching, but practically in Scheme what would that look like.
<roptat>(let ((which-file-failed (match rest ((_ _ file) file)))) ...)
<rovanion>Thank you!
<roptat>(well, I'm not sure exactly which position it's at
<roptat>you need (ice-9 match) to be able to use match
<rovanion>But something along those lines.
<roptat>you might want to name other positions too, to be more clear
<roptat>or maybe even better, you could do that on the args match: ('system-error "open-file" . rest) becomes ('system-error "open-file" _ which-file-failed . rest)
<muzueufoia>roptat: Thanks again for the manual link. I got a configuration to build. Restarting now to see if graphical login now works on startup...
<muzueufoia>I have a graphical desktop environment now. Thanks!
<roptat>don't forget to run guix pull and update your system to get the latest and greatest :)
<foomar>I'm back, as I asked earlier: do you have any advice about rewriting the `login-service' so that it doesn't use PAM?
<jlicht>wondering if something could go to master; "5880 packages would ensure 12039 dependent packages are rebuilt"
<jlicht>guess not :)
<jonsger>jlicht: what are you trying to fix?
<ngz>Do we know why the page is stuck?
<nckx>The whole site isn't being built; throws an error.
<mekeor[m]>/me writes this in emacs via matrix with a self packaged emacs-ement.el on guix-system