IRC channel logs
2023-07-17.log
back to list of logs
<janneke>civodul: the commits above that are for native building, starting with guile... <civodul>janneke: ah ok; if you think those 7 commits are "safe" enough, i guess we can go with that <civodul>do you need additional feedback on these? <janneke>civodul: yes, iwbn if someone looked at those -- and i believe jpoiret is doing that / has been doing that today? <nckx>Use (this-package-input "hello"). This might require a quick conversion to gexps, but I'm not going to suggest %build-inputs. <nckx>ACTION didn't realise that the Disruptor would cross the bridge. <bjc>is there a reason to use ‘(this-package-input "hello")’ over a plain ‘#$hello’? <nckx>Yes, input substitution. <bjc>from transformations? <nckx>Yes. Hard-coding the exact hello package won't magically follow them. <bjc>how new is ‘this-package-input’? it feels like i've only recently started seeing it, and previous things i submitted used plain ‘#$’ and no one complained <gabber>bjc: i'd like to second this question <nckx>There was this bot in the ol' Matrix room, I have no idea whose, that injects the cats into les chats. <nckx>Now that we're bridged, it joins in the fun with URLs on IRC. <nckx>bjc: I don't have a date for ya, but you could grep the log. It's not *that* new. <bjc>we talking months or years? <nckx>I... have no sense of time. <gabber>also: nckx: are you back from some kind of sabbatical or something (no need to comment)? i think didn't see you here for quite some time... just wanted to express my joy meeting you here again! <nckx>Happy birthday this-package. <gabber>but i don't think i've ever seen it (not that this is any indication of anything :P) <bjc>freed from its bastiile <gabber>oh wow, barely expected any activity in here... but this is func! <gabber>soooo... what should i take away from this error message: `Unknown # object: "#<"' ? <gabber>i've changed the line in question to ,(this-package-input "hello") <nckx>That something got written to a builder than shouldn't, basically. <nckx>Did you switch to gexps? <gabber>i don't think so -- i only changed that line 42 <nckx>(arguments (list #:phases #~(modify-phases ... #$(this-package-input "foo") ...) ...) ; roughly <gabber>ah.. i should have switched to gexps (: <nckx>After importing (guix gexp). <nckx>Sorry, I'd do it for you if I could. <gabber>it's always a fun little adventure gexp-izing stuff, but please don't let me (or whatever it is) hold you back ;) <nckx>Just that I'm still stuck on a 'phone. <nckx>I installed Emacs, but it doesn't come with a control key. <gabber>i know, but i thought this was either some kind of a joke or for people who actually use their phones or tablets or TVs or fridges with a keyboard <nckx>I actually do use Emacs in Termux (which thoughtfully includes a control key) several times a day, but it's not *fun*. <nckx>ACTION was away. XDG_RUNTIME_DIR=/run/user/1000. The last time I guessed who set it, I said elogind. <gabber>it's the lack of a soft-keyboard Control key, i guess <nckx>Maybe it could if it provided a virtual control key. <nckx>I don't have a hardware keyboard. <gabber>last time i tried to Ctrl-C something in Termux i ended up screenshotting a bunch of stuff while losing my shits pretty much simultaneously <nckx>No, the key (hopefully two) on your keyboard that says Ctrl or Strg or… <gabber>with control, alt, shift AND meta keys <gabber>and the good old ANY key while we're at it <nckx>You're more likely to get a hardware emoji keyboard. <gabber>i saw those recently! while re-watching Idiocracy <gabber>ok, now i get a "'replace' may only be used within 'modify-inputs'".. but i'm like.. at least 40% sure this part is actually correct!? https://termbin.com/a2d7 <nckx>(modify-phases → #~(modify-phases ? <gabber>.. but why? i didn't change anything down there? <nckx>Same for (list "-march=rv64g"). <nckx>You turned the arguments into a list call from a quoted sexp. <nckx>So all its contents change their nature too. <gabber>i did? or i should have done that? <nckx>This is getting confusing fast. <gabber>well, the expression (still) starts with `(arguments (list ...))' <nckx>Didn't it start with (arguments `(… before? <gabber>but i changed all the expressions as you told me and now we're compiling so.... <lamer2000>hi all! here they can help with the question of installing guix or am I not here? <lamer2000>this line spins for a very long time and then reports an installation error <oriansj>lamer2000: well openssh would be a service not a package if you want to setup a server; if your goal is install the openssh client and guix package install openssh should work <oriansj>lamer2000: did you do guix pull first? <oriansj>and you did the steps shown by guix after the pull correct? <oriansj>and the guix service is running on your system? <lamer2000>and guix can't reach sites with repositories <mirai>lamer2000: can you ping ci.guix.gnu.org at all? <mirai>I'm suspecting a firewall issue <lamer2000>I can't open this site in my browser and curl can't reach me either <lamer2000>yes, provider is blocking access to the ip address <ChocolettePalett>I suggest using "bordeaux.guix.gnu.org" substitute server instead of "ci" one then <lamer2000>how do i use a mirror when installing a guix system? <lamer2000>do i need to put this in my config for it to work? <lamer2000> (q #7D602902D3A2DBB83F8A0FB98602A754C5493B0B778C8D1DD4E0F41DE14DE34F#) <lamer2001>is there a way to install guix OS without internet connection? <lamer2001>I got the iso from the official site, but its installer requires mandatory network access <lamer2001>Are there any unofficial releases for offline installation somewhere? <Michal_Atlas[m]>You could create a release yourself. It's quite simple to generate a installation image with `guix system image` and if you include all the packages you're gonna use then it shouldn't need to download anything <htgoebel>When building a system image in qcow2 format. fakeroot fails with "Not enough space to build <htgoebel> proposed filesystem while setting up superblock". <efraim>do you have enough space in your /tmp? that'd be the first thing I'd check <efraim>is the size of the image 'guess? <efraim>can you build it with --no-grafts and have it fit? <htgoebel>efaim: thx. /tmp has 1.4 GB of space, which I expect to be enough for a small sample machine. <htgoebel>efraim: solved by *not* passing --image-size <htgoebel>efaim: and for --image-size I missed passing a size unit anyway :-/ — 10 bytes are obviously to small <Rovanion>Thank you for time-machine by the way! Allowed me to time-travel back to when Gimp had Python 2 support yesterday! <nckx>They helpfully attached a full copy of the sensitive secret in plaintext. <htgoebel>nckx: lol - if the internet's security is based on such researchers it is lost <rekado>I’m trying to upgrade an x86_64 system that hasn’t been connected to the internet for maybe 6 months or so <sneek>Welcome back rekado, you have 1 message! <sneek>rekado, ngz says: Do you remember why "artistic2" license in texlive importer is bound to gpl3+ instead of artistic2.0? <phpenjoyer>I think that something could be wrong with ``frama-c`` package, as it fails to build on my system... I checked the logs and it failed on linking stuff with "ld: cannot find -lz: No such file or directory". I guess I should file a bug? <rekado>I’m getting a 504 response from ci.guix.gnu.org <rekado>sneek: later tell ngz The artistic2.0 -> gpl3+ thing looks like a mistake <rekado>it get the 504 response for lzip substitutes <rekado>wget doesn’t have a problem with the URL <gabber`>i'm trying to get a Jenkins pipeline to work with my Guix based shell and i'm having troubles updating Guix on that (non-guix) machine. i `guix pull`ed both with and without `sudo -i` and restarted the service but for the unprivileged user `guix -V` still reports 1.2.0 :( what am i missing? <nckx>phpenjoyer: Thank you! I'm building it here, let's see what's going on. I also see there's a new version, let's see if it builds… <phpenjoyer>gabber: As far as I remember, you also need to do "hash guix" or something like this, and probably source your guix profile, because your environment variables could be referring to an older guix installation <nckx>(And use ‘type guix’, not ‘which guix’, to check.) <Martin[m]>hello, why guix is still using by default linux-6.3.13 [EOL] ? <nckx>Feels like a trick question, but: because it's not out of date in any meaningful sense and nobody has updated the default yet. Possibly because of aarch64 build issues, if memory serves. lfam is the best person to ask but they aren't here. <nckx>Rather, my initial ‘…because it hasn't been bumped to 6.4’ felt like a trick answer. <jpoiret>the EOL announcement was 6 days ago only <nckx>It's there, just not bound to linux-libre. <nckx>(The announcement is also a releas, so there's some time barring any weirdo CVEs.) <Martin[m]>it could be bumped to 6.4 or 6.1 both cases are better than EOL, isn't it? <nckx>Not if 6.4's broken on aarch64. <nckx>I don't see why 6.1 is better, but I recommend simply using linux-libre-6.4 yourself if you're worried about this. <nckx>‘EOL’ doesn't mean ‘stop using ASAP’. <nckx>Can anyone get ‘guix shell tome4 -- tome4’ to display a menu? Or anything more than a white screen? <rekado>nckx: didn’t expect a game to pop up when running the command, heh <bjc>it flashed a screen up briefly for me before it turned white, but i couldn't tell what it was. some kind of game, i guess <rekado>I just ran it and I hear repetitive music, a very quick flash of some image, and then a white screen <rekado>the game cursor is rendered, though <bjc>i just mean its with wayland, maybe its different with x <nckx>OK, so it's not my oldish GPU. Thanks all. <bjc>i'm on an igpu from skylake, so it's not exactly new either <nckx>ACTION won't trick you into gaming again. <efraim>Loading WebCore: Failed loading /gnu/store/frrmxhg0vkkf564lq5ik25wkf625yhbj-tome4-1.7.4/share/tome4/libte4-web.so <nckx>When I run it with DISPLAY=, it segfaults. <efraim>ocalhost vmunix: [14821.690780] t-engine[30293]: segfault at 968 ip 00007fa73cb80f50 sp 00007fffea290970 error 4 in libX11.so.6.4.0[7fa73cb64000+87000] likely on CPU 16 (core 5, socket 0) <nckx>int main() { nibble nr_cores; /* should be enough for anyone */ … } <nckx>I bet you spell it ‘automagically’, too. <bjc>for hysterical raisins <rekado>nckx: it works for me when I edit ~/.t-engine/4.0/settings/resolution.cfg to contain window.size = '800x600 Windowed' <nckx>I tried that already and it makes no difference, but it's good to know there's a working configuration out there. <nckx>Correction: it makes the white screen a black window. <nckx>I tried again with Sway explicitly configured not to tile it from the start (so it doesn't get a resize event), but no difference. <rekado>it did not work with the detected default resolution <rekado>I had to lower it to 800x600 to get a window with actual contents other than white <nckx>(Coincidence; and nostalgia; I guess.) <Guest28>My nouveau driver makes a kernel panic on GNU Guix with Libre Kernel. There are also tons of gran_size warnings. I bootet Trisquel 11 and there is nothing. I only have that issue if I want to use my GPU on GNU Guix. <Guest28>With my Intel iGPU is nothing as well. <Guest28>It can't be a hardware issue since other distributions work. <Guest28>I had that issue already with Kernel 5.x <RavenJoad>I want to create a named environment that I can run "guix shell" on for common tasks. I have a packages->manifest defined for video downloading with yt-dlp. Right now I need to pass the path with -m. Should I turn this into a package with no source and no version? <rekado>RavenJoad: “guix shell” (without any arguments) will use the manifest in the current directory, once authorized. <RavenJoad>rekado: These are not project shells, but convenience shells. They pull together packages I use for occasional tasks. It is a QoL thing, but I do not want to have to cd to the directory with the manifest to open a shell. <rekado>have you considered defining a shell alias then? <bjc>what's the magic incantation to get ‘make check’ to just run the tests from a specific tests/foo.scm file? <nckx>make check TESTS=tests/foo.scm <nckx>There is advanced support for space-based arrays. <RavenJoad>rekado: I had not. I already have my own channel, so I figured I could piggyback off of Guix's method of finding packages to find my shells. <graywolf>Is there something like file-prepend function? I cannot find it in the programming index, but file-append seems to care about what argument is what. <dwinkley12>(kinda maybe sorta belongs here): whats a cheap wifi card i could put in my thinkpad e130 with foss firmware available to it? <Retropikzel[m]>I'm getting "ld: cannot find -lrt: No such file or directory" in guix shell when trying to build stuff with rust or haskell. gcc-toolchain and rust/haskell stuff installed. What package has -lrt? <bjc>mumi seems to be down <Retropikzel[m]>Retropikzel[m]: I tried searching but currently I do not even now what it is. So even that knowledge would be nice <mfg[m]>Retropikzel[m]: i think this is the compiler_rt library; this should be part of calng-toolchain or a standalone packege <mfg[m]>s/compiler_rt/compiler\_rt/, s/calng/clang/, s/packege/package/ <mfg[m]>mfg[m]: Ah the package is clang-runtime <Retropikzel[m]>Retropikzel[m]: Since I'm compiling it seems that clang-toolchain is needed, clang-runtime is not enough. Problem solved anyway :) <nckx>Surely there's a path to -lrt without pulling in an entire second compiler toolchain. <bjc>is there a reason we segregate static to its own output? <nckx>I like doing so to discourage static linking. And very occasionally, size. <bjc>without the -static flag, won't shared be used when possible anyway? <bjc>i don't see much point to it, then, although it was at least pretty harmless until recently <bjc>now, though, it appears to me the calculus has changed <nckx>We still don't want packages to silently link statically. <bjc>because the removal of -lpthread and -lrt have caused a fair amount of gnashing of teeth <nckx>I see: I was talking generally. <bjc>maybe then the best option is to add the stub .a compat files for them, then <nckx>I'm not against adding those specific files back if they were recently split off. <nckx>But in general Guix packages installing .a files that can be silently linked into dependents is IMO not a good thing. <bjc>glibc merged them into libc, and provides empty .a files for them for compatibility <bjc>so the current solution when you need them is to pull in the entire static toolchain, which seems like a pretty bad option <dwinkley>hello! so can someone like give a list of what wifi cards/wifi dongles i could get that guix supports(since it obviously blacklists non foss firmware) <anemofilia>I am having a lot of problems in a fresh guix install <anemofilia>My OS and home declaration were working perfectly on the same machine, but a different SSD <anemofilia>Just reinstalled it in my main ssd and now a lot of stuff is broken <anemofilia>Also even weechat is broken now, I don't know if I am properly using the emacs irc client, it would be helpful to see someone's message here <Guest28>Did you change the filesystem? Does the SSD may have problems? Other than that I have no clue <anemofilia>Also I used the exact same iso that I used to install in the other ssd <Guest28>Hmmm, so the initial install is with the same commit if you use the same install ISO. Well, one of the reasons people use Guix is for it consistency and ironically it complete broke <Guest28>I can't help you (not experienced enough) but could you maybe just try again and see if it works? <rekado>anemofilia: did you receive an issue number? <rekado>the output you posted looks like file system corruption to me <anemofilia>I did, but the site doesn't even load anymore here for some reason <rekado>anemofilia: what’s the issue number? <anemofilia>Or just enabling a specific mirror as substitute url <Guest28>502 bad gateways for issues.guix.gnu.org <rekado>you accessed it right when I restarted it <rekado>(there is a problem with debbugs.gnu.org; we can’t reach its rsync daemon) <Guest28>If rekado means filesystem corruption, the ssd where system is installed on, or do you mean maybe the device from the iso itself? <rekado>anemofilia: I’ll try to reproduce this by running “guix pull” myself <Guest28>Yesterday I installed Guix with a USB stick that had a lot of io issues. Got many different kind of weird errors, too. <rekado>the backtrace looks like the guix client doesn’t talk well with the daemon <rekado>anemofilia: this is Guix System, right? Not Guix on top of a foreign distribution? <rekado>FWIW “guix pull” just completed for me without erros <Guest28>Well, he said with the exact same ISO worked last time. So I guess the commit itself should be fine <Guest28>Ah, I misunderstood. The installation went fine but now the OS is in some weird state that guix pull, wechat and so on is not working <rekado>what does the weechat error look like? <anemofilia>Well, since I can't run `guix pull` I wouldn't say it went fine, but yes <rekado>do you have a working network connection? <anemofilia>And everything I type can't be `erased` forgot the word <anemofilia>when I try to remove the text I get some strange things <rekado>have you run fsck to rule out file system corruption? <rekado>anemofilia: I’m not convinced it’s file system corruption, but it’s a good idea to make sure before getting lost in the weeds <rekado>(we can get lost later, there’s no rush) <anemofilia>I boot on a pendrive and run fsck /dev/sda1? Just that? <nckx>Or boot with fsck.mode=force. <radio>I don't know how to use irc on emacs yet. Is it working now? <radio>rekado: I've fschecked the partition and seems it's fine <radio>But still am getting the compute-guix-derivation error <kiranshila>Hey everyone - does anyone have access to the guix-devel email list admin? I'm trying to unsubscribe from the mailing list but I never get the confirmation email when I request it. <efraim>uh, I have some access to the controls <viaken>I'm trying to build an install image and it's throwing an error trying to install grub: "failed to get canonical path of <encrypted LVM partition>" - Why does it even need to look at my hard drive partitions? <viaken>I tried with --no-bootloader and it didn't help <nckx>efraim: You taken care of it? <civodul>janneke: hey! i'm (finally!) looking at the bottom of the hurd-team branch <civodul>there are -boot0 packages that refer to cgit-generated tarballs as their source <civodul>i think we should avoid that, because those generated tarballs tend to change over time <civodul>(the file therein remain the same, but metadata changes) <civodul>is there an issue on guix-patches for this part? <civodul>the hurd/gnumach/mig updates in commencement.scm are required to build glibc 2.37, right? <janneke>civodul: no, i haven't created an issue (yet) <janneke>civodul: i was hoping that the cgit tarball would either be stable, or that software heritage help us out if it ever changed <civodul>janneke: we cannot count too much on that; at least we never do that, 'guix lint' warns against it (but for github.com, not for cgit instances) <civodul>i mean SWH + our Disarchive job may archive it before it changes, but that sounds too risky <civodul>also there's currently no fallback upon hash mismatches <civodul>so right now we have neither cross-compilation support nor native compilation, right? <janneke>yeah, terrible; i believed we were nearly there <civodul>i think we should try to merge chunks that get us from known-good to known-good :-) <janneke>and also, that we had a nice solution going forward <janneke>we'll probably see quite some updates that upstream doesn't make releases for <civodul>well there's a lot of great work there waiting for us on the branch! <janneke>so jpoiret and i figured: use cgit/tarballs for commencement, use git for hurd.scm <civodul>to me generated tarballs remain something to avoid, even more so for core components <civodul>i'd just "make dist" the things and upload them <janneke>so, would your solving your 2) problem (iirc) be feasible, i.e., breaking the git cyclic dependency <civodul>and mention it to upstream, just so they know <janneke>yeah, that seems to be the best alternative right now <civodul>but that's a long-term solution: we won't be able to assume guix-daemon supports it <civodul>another option might be to play tricks with fixed-output derivations <civodul>but right now we're looking for a hot-fix kind of solution :-) <jpoiret>cross building was okay until the mig update was reverted because it broke the data service <jpoiret>i'm trying to get the branch working with the spanw patches <RavenJoad>Can I make a package->manifest show up with guix search? Or does that only find packages? <civodul>jpoiret: yeah; specifically the mig update made it impossible to compute derivations for i586-gnu <jpoiret>yep, i hadn't thought of that before pushing, since native compilation was broken anyways <jpoiret>but if the cgit tarballs are not possible, then it's going to be a bit more painful <civodul>right it's easily overlooked, too many things to pay attention to <civodul>it sorta mitigates the fact that we're relying on unstable tarballs <civodul>by stacking another fixed-output derivation on top of it, one that's equivalent to a Git checkout <civodul>actually we can prolly simplify this <civodul>we cannot use Guile HTTP client on the build side at this stage <civodul>you write: (method (git-fetch-from-tarball (origin ...))) <civodul>a hack, but at least we'd get some help from SWH <civodul>and we'd be mostly immune to changes of the generated tarball <civodul>i can't reconfigure right now because no childhurd <civodul>shouldn't we upload a mig tarball and reinstate the mig upgrade to use it? 
