<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.
<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)
<dragestil>trying to install guix for the second time, getting substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0%guix substitute: error: TLS error in procedure 'write_to_session_record_port': Error in the push function.
<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.
<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 :(
<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 hpc.guix.info 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
<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
<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.
<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.
<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 irc.himmler.de or whatever, I understand, but if there are literally Nazi comments in guix build --source that's a big one.
<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.
<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.”
<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
<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?
<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>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>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.
<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>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"))
<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
<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
<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>(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.)