<FennecCode>Hey, so I noticed that it's been a while since GZDoom has been updated. It's a few versions behind now. Is that because of some licensing issue that I'm not noticing, or is it because of a technical issue that's being avoided? <nckx>ruffni: You're writing a package; you probably want ‘gcc’. And yes (it should be a native-input because it runs during the build; imagine you're cross-compiling to see why). <nckx>FennecCode: I don't think it was for licencing reasons. You can diff the old and new code to make sure. *nckx vaguely remembers looking at updating gzdoom but has no idea what happened next… <dstolfa>nckx: would there be any interest in guix + distcc? <oriansj>dstolfa: guix is a scheme program, compiled by the scheme interpreter/compiler guile. Or do you mean something along the lines of enabling one to one to select an alternate C compiler when compiling packages? <dstolfa>oriansj: the latter, so one could deal with updates when substitutes are not available on old laptops *nckx recommends diffoscope. *vagrantc doesn't know what the issue is, but also recommends diffoscope <nckx>‘It hurts whe—’ ‘diffoscope.’ <vagrantc>dstolfa: it woudl kind of kill the functional package management model to have some packages built one way and some built another... <dstolfa>vagrantc: why? if you have 3 guix machines just building C or C++ files? <dstolfa>for example, at home i have 3 computers i could leverage for distcc builds of certain things, which i already do for some things but not in guix <oriansj>dstolfa: it is more to do with given a package definition and a known guix commit, the resulting binary should always be exactly the same. <nckx>dstolfa: It certainly complicates matters. There's currently a blanket ban on network access from within the build environment. That doesn't make everything magically reproducible, but dropping it would open some interesting floodgates. You'd have to ensure that only distcc can communicate. Then there's the fact that Guix already supports offloading entire builds, so you'd be introducing all that complexity for a relatively minor bump in granularity from <nckx>Great when you're building Chromium for the week-end, but is it worth it? <dstolfa>i guess it's more of a niche thing. it kind of depends on how often you build something like chromium :) <nckx>At least Guix would be able to ensure some sanity compared to the average distcc farm: you can actually enforce that each node builds packages with the exact same GCC store item, not merely the same version. *nckx trying hard to be ‘balanced’; probably shows. <hiruji>I was wondering if there's any way for me to disable package tests on a global level? <rekado>hiruji: this would result in rebuilding *everything* from source. Is this acceptable? <hiruji>Yes, actually I was asking how to rebuild everything from source the other day ;p <nckx>Changing a detail like ‘don't run any of the tests’ for each package is one way. <nckx>It won't change the packages whose tests are already disabled but they likely have another as input that will change, so they'll get rebuilt too. <nckx>Save time by rebuilding the world from scratch 😉 <ixmpp>How do i reinstall the bootloader <zacchae[m]>I'm going through the docs setting up my system config from scratch (first install). How do I find the value of variables like %base-services? The docs just say it include "a list of basic services one would expect from the system" <vagrantc>ixmpp: somewhat depends on which bootloader ... but guix system reconfigure typically will reinstall the bootloader every time <ixmpp>It is not doing so correctly, then >_> <nckx>You can invoke grub-install manually. <nckx>There's no magic that Guix adds. <nckx>It's OK GRUB itself already has dangerous levels of magick. <lambdalove-sadvi>Hi, folks! Installed guix a few days ago and I'm still trying to make it boot... mounted the fs at /mnt/guix and was grepping through the /var/log/* files, but couldn't find any hint besides some ntpd resolving error; any further tips on how to check it up? <lambdalove-sadvi>Oh, and this: log/gdm/greeter.log:/gnu/store/ypij6xc3i9a5ksa20y44m5528jcs5a29-xorg-server-1.20.10/bin/X: symbol lookup error: /gnu/store/ix394p9k56kvfk8vzsxggrglm25szznr-xf86-video-ati-19.1.0/lib/xorg/modules/drivers/radeon_drv.so: undefined symbol: exaGetPixmapDriverPrivate ; does that mean my GPU isn't compatible? <lambdalove-sadvi>It goes like this: my guix only has xf86-video-amdgpu which is loaded by default. the kernel driver is blacklisted by linux-libre and won't work with linux-libre even if you install the firmware <lambdalove-sadvi><terpri>(or maybe "blacklisted" is the wrong word, but it definitely refused to load any firmware last time i tried) <lambdalove-sadvi><terpri>for recent amd gpus to work, you'd have to use the (non-libre) linux kernel and the standard linux-firmware repo (both of which are insufficiently free by guix standards) <zacchae[m]>No one ask why, but can GUIX run fine with a partitionless setup? <apteryx>you mean a single partition spanning the full storage device? <zacchae[m]> * no, as in running `mkfs.btrfs /dev/sda`, so there is actually no partition table <ixmpp>zacchae[m]: How will you boot? <ixmpp>Oh, grub supports btrfs now, forgot <ixmpp>Curious to see if you manage it. <ixmpp>How would i best modify the guix-daemon service to add environment vars to it's forkexec <zacchae[m]>I believe it is possible with UEFI, though I can't confirm as current machine doesn't have UEFI <zacchae[m]>You just need a subvolume for your root directory. I've done it before with arch <bricewge>lxmpp: Good question I don't know a simple way to do that. It would ha been straightforward with NixOS or systemd. <bricewge>Why do you need to change guix-daemon environement? Which ones ? <ixmpp>bricewge: Wanted to set GUIX_STATE_DIRECTORY <ixmpp>It's set globally, but that service doesnt inherit it <ixmpp>I feel like there should be a way to hack this in <ixmpp>Without just editing the guix code <bricewge>GUIX_STATE_DIRECTORY isn't even documented <bricewge>That would be a really usefull feature, when not all of a daemon configuration is reachable through it's service <The_tubular>guix system: warning: cannot determine provenance for current system <The_tubular>guix system: warning: cannot determine provenance of GNU Guix <The_tubular>I cannot use guix pull, as it just crash with a lot of useless output <apteryx>I managed to get the deb produced by guix pack to work with --symlink, so now it can tack guix binaries onto the foreign distro FHS search paths ;-) <apteryx>On the Debian-based VM: sudo dpkg -i vg183bhb2gjjzniqw3awxz4b5zwjlm3m-deb-pack.deb && realpath /usr/bin/hello -> /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10/bin/hello; /usr/bin/hello -> Hello, world! Fun! <bricewge>Can you remove it cleanly too? Not like the usual pack, where you need to force the deletion of file in the "store" as root <apteryx>If I install a same named deb on top it does remove it cleanly before reinstalling it <apteryx>I think you can also uninstall it via dpkg (not sure with apt... I think it'd expect to find some repository metadata about it). Many things to try :-) <apteryx>oh, it works: sudo apt purge deb-pack <apteryx>(the generic name is 'deb-pack' so far) <apteryx>Removing deb-pack (0.0.0) ..., and all its files are gone <apteryx>bricewge: by the way, very nice to have you back here :-) You were missed for a while! <chaos`>Hi, I'm getting the following error when trying to install guix-1.3.0 from a usb stick: <chaos`>root@gnu ~# guix system init /mnt/etc/config.scm /mnt <chaos`>... /gnu/store/f48n4dfcjgkghiphn40sp2jbb4p5dw8m-system <chaos`>/gnu/store/3gfnkx6y6llsafhry5rhalgsmn7ay1mj-grub.cfg <chaos`>initializing operating system under '/mnt'... <chaos`>guix system: error: fport_read: Input/output error <chaos`>.. so getting the fport_read Input/output error when trying to install guix either manually or using the graphical interface. any idea where to start looking for the cause of the error? <apteryx>did you do 'herd start cow-store /mnt' as mentionned in the manual? <apteryx>it's at the top of 3.6.2 Proceeding with the Installation <chaos`>Perhaps I didn't do it when trying with manual installation (I only did so that I could copy paste the log), but I do get the same error when trying the graphical interface (I assume the cow-store is explicitly performed there) <chaos`>let me try again with manual installation <chaos`>root@gnu ~# herd start cow-store /mnt <chaos`>Service cow-store has been started. <chaos`>root@gnu ~# guix system init /mnt/etc/config.scm /mnt <chaos`>/gnu/store/hn2snl55zi1qp0mr4waax8dyns1d7kqy-system <chaos`>/gnu/store/0p5birjab109ca92klyqw79qhvywkxwx-grub.cfg <chaos`>initializing operating system under '/mnt'... <chaos`>guix system: error: fport_read: Input/output error <chaos`>(I've run the above commands on top of an existing graphical installation that has failed with the previous error message) <chaos`>Filesystem 1K-blocks Used Available Use% Mounted on <chaos`>/dev/sda2 50488848 4175896 43718496 9% /mnt <chaos`>tmpfs 1982436 0 1982436 0% /dev/shm <chaos`>none 50488848 4175896 43718496 9% /gnu/store <chaos`>/dev/sda6 98671792 61464 93555048 1% /mnt/home <chaos`>Sector size (logical/physical): 512B/512B <chaos`>Number Start End Size Type File system Flags <chaos`> 1 1049kB 3146kB 2097kB primary ext4 <chaos`> 2 3146kB 52.8GB 52.8GB primary ext4 boot <chaos`> 5 52.8GB 56.8GB 3998MB logical linux-swap(v1) <chaos`> 6 56.8GB 160GB 103GB logical ext4 <chaos`>Sector size (logical/physical): 512B/512B <chaos`>Number Start End Size Type File system Flags <chaos`> 2 639MB 642MB 2949kB primary esp <chaos`>(some more info on my disk setup above) <bricewge>apteryx: Life got in the way, but I'll try to contribute more now <apteryx>chaos`: otherwise thanks for the info! It's too late for me to have a clue unfortunately; I hope someone else can tip in if they have an idea! <bricewge>apteryx: So thanks to your new pack format, I'll be able to properly install alacritty on my Debian 10 workstation neat <bricewge>If you need some more testing, I can give you a hand <bricewge>chaos`: Did you reboot between your manual and graphical installation tries? <chaos`>bricewge: No I haven't, let me start from scratch again <florosGPL>I am on some Yocto build and I need gtk+. I installed it and there are multiple /gnu/store/<hash>-gtk+-2.24.24/ installations and .../gtk+-2.24.24-bin/. The binaries are not available via the $PATH after installation. Is there a command to reconfigure things? I tried to run garbage collection and it deleted more than it should <florosGPL>I did a plain guix install gtk+, I didn't use gtk+:bin (if I get it correctly) <bricewge>When not specified, the default output used is "out" <florosGPL>thanks bricewge. With your feedback I checked a 3rd party guide and found exactly what I did wrong. I sure missed the :bin when I was reading the official manual. <raghavgururajan>Following `/gnu/store/…-run-vm.sh -m 1024 -smp 2 -net user,model=virtio-net-pci <raghavgururajan>` from manual, gives this error `qemu-system-x86_64: -net user,model=virtio-net-pci: Invalid parameter 'model'`. Thoughts? ***o is now known as niko
<nckx>raghavgururajan: That example is obsolete (because -net is) and needs to be updated. <nckx>raghavgururajan: Seems to be as simple as s/-net/-nic/. QEMU accepts it here, but I'm on battery and can't afford to build a VM. Could you test whether the effect is also the same? <nckx>chaos`: If that happens again, the output of the ‘dmesg’ command should be enlightening. <florosGPL>Is there anything similar to guix install package:bin but for libraries? <bricewge>It depends on the outputs a package produce, as an example "nauty" does (see “guix show nauty”) but most packages don't <chaos`>(initializing operating system under '/mnt'... <chaos`>guix system: error: fport_read: Input/output error) <bricewge>chaos`: What about dmesg output as nckx suggested? <nckx>If the I/O error is at all ‘legitimate’ it will be logged there. <nckx>raghavgururajan: Will update, thanks. <nckx>OK, something's gone wrong whilst writing your installation ISO to the (probably USB) medium. It seems the write was incomplete. <nckx>[sdf, your 32GB sticky friend] attempt to access beyond end of device <chaos`>I see, thanks! let me rewrite the ISO image then <ss2>is ci.guix.gnu.org down? <nckx>Try that, and make sure to sync before removing it (Linux caches heavily and might not even start to write a mere gigabyte until you sync). <ss2>I can't ping it, and guix pull is failing at fetching substitutes. <ss2>Or is nagging really. A couple of minutes ago it was complaining about it being slow. <nckx>It's historically never responded to pings unless that firewall hole was finally opened to help confused users. <nckx>But it sure looks unresponsive over HTTP. <nckx>I got the certificate prompt after a full half minute. <nckx>Load average: 3.71 4.49 4.45 <ss2>yeah, seems fine now. <urawnn>Hi all, I'm coming from gentoo, and been trying guix out. It's pretty amazing, I'll likely be migrating over the next few weeks <urawnn>I hit a question though, if I want to compile everything from source, using my custom-built build farm, is there a way to build packages with distcc? <urawnn>from reading the docs, I realized one can offload builds to other machines, but from my understanding, one can offload each package build to each machine, instead of using multiple machines to build one package <dstolfa>urawnn: in short: not without some work, but you can offload builds of packages <nckx>No distcc bu package-level (really: derivation-level) offloading is supported. <dstolfa>it's not quite the same as distcc, but it does the job <urawnn>cool, thank you! uhm, would the work required actually just install and configure distcc and when guix try to build locally, distcc does its thing? <urawnn>since it replaces gcc with symlinks to distcc, afaik <dstolfa>distcc load balances and dispatches compile jobs of the same package to different machines <dstolfa>offloading in guix shoots off package builds to other machines <dstolfa>it doesn't distribute the build of the package itself <nckx>The build environment isn't ‘random stuff I have lying around on my machine’, it's closed, both from the network & from the rest of your file system. <urawnn>right, thank you, I understand now the challenges <nckx>In that link, ‘interesting’ should be read with the quotes I forgot to add then 😉 <urawnn>I guess having a big machine will do a better job than having a couple dozen cheap arm boards <urawnn>thanks a lot, I'll return later once I get a local install going that isn't a vm <civodul>dstolfa: i don't think distcc would be very useful, and it's pratically impossible to incorporate it <civodul>i recommend giving offloading a try! <dstolfa>civodul: well "useful" is relative. it would be useful to me, but it's not exactly a must have <dstolfa>basically, would be nice, but can live without kind of thing <nckx>After a brief walk around the house, I should say that I'm not sceptical of adding distcc/ccache-like functionality to Guix (I'm not interested but it would be an awesome hack) — I'm sceptical of cutting distcc/ccache-shaped holes in the build environment isolation. <nckx>Yes, basically rewriting their features in Guile, yes :) <civodul>right, that's what i meant by "practically impossible" :-) <nckx>It would be very cool, because you could use Guix features to get very close to transparent builds, but civodul is right, we can't actually buy interns by the dozen. <dstolfa>nckx: yeah, i agree that doing this in guile would be way better <raghavgururajan>nckx: Do you know how to make polkit-auth work for user installed packages? For example. if your try installing and running bitmast (https://issues.guix.gnu.org/48729 - v4), the polkit-auth fails. The policy file installed in correct location. <nckx>I'm afraid I'm really not into the whole Freedesktop stack. I think it's important to support and am glad you help do so, but I don't actually *use* it. <leoprikler>raghavgururajan: it's probably a good idea to add glibc to your environment for the propagation of XDG_DATA_DIRs <ss2>Is there a possibility to pin a package in the store? I deleted texlive -- again. <rekado_>ss2: yes, use “guix build --root=/where/you/want/it texlive” <rekado_>but I recommend not using the “texlive” package at all. <rekado_>if it’s installed in a profile it will not be deleted <rekado_>so is it in the store as an input to some other package? <rekado_>if so, that’s wrong and the package should be changed to use texlive-union <ss2>What would be the alternative to texlive? I pinned it in my declaration, hoping it would stick there a bit. But that wasn't the case after all. <dstolfa>what's wrong with the texlive package (apart from texlive-bin not playing well with it)? <dstolfa>i have a love hate relationship with tex & family <ss2>rekado_: alright, will try that. Neat! I hadn't seen this feature yet. <dstolfa>on one hand, it beats the hell out of libreoffice & co, but on the other hand, my god is it awful <viivien>I love how beautiful it is, until "undefined control sequence \begin{document}" <dstolfa>or when you have maths packages which fight each other <dstolfa>and you can't use them both in the same block <ecbrown>how could you not want all those beautiful documents/vignettes in CTAN <mschilli>I ran into an issue trying to build Guix from source: <mschilli>after ./bootstrap && ./configure --localstatedir=/var, make fails: <mschilli>doc/contributing.de.texi:1697: @pxref reference to nonexistent node `Synopses <mschilli>doc/contributing.de.texi:1791: @xref reference to nonexistent node `Writing <mschilli>make[2]: *** [Makefile:4543: doc/guix.de.info] Error 1 <mschilli>make[2]: Leaving directory '/home/mschilli/guix' <mschilli>make[1]: *** [Makefile:5983: all-recursive] Error 1 <mschilli>make[1]: Leaving directory '/home/mschilli/guix' <ss2>Sorry that I have to say this: but could you please use a pastebin? <mschilli>ss2: Sorry. My bad. Should I repost the lines above via a pastbin or just abstain from future spamming? <ecbrown>mschilli: have you entered a `guix environment guix --ad-hoc strace graphviz help2man' e <ss2>No worries, just abstain for the future; they're paste services around, e.g.: paste.debian.net <ecbrown>sometimes i forget and i get nonsense when i try to build ~/src/guix <mschilli>ecbrown: I did not have graphviz, do I need to re-configure in the new environment? Or boostrap again even? Any make clean before that? <ecbrown>mschilli: my advice: move the whole guix directory out of the way and re-clone <ecbrown>then open a brand new terminal window and then enter the directory, then execute the environment command and try again <ecbrown>(its probably salvagable but i don't like uncertainty when helping debug) <mschilli>ecbrown: Alright. I'll report back in an hour or two then. ;-) Thx! <nckx>ss2: What does ‘pinned it in my declaration’ mean? <mschilli>ecbrown: No clue why it was so fast this time but I got the same error using a fresh clone. <mschilli>This was from guix environment guix --pure --ad-hoc help2man graphviz strace -- bash ***nee is now known as Guest4619
***stikonas_ is now known as stikonas
<ecbrown>mschilli: why do you put bash there? <ecbrown>would that spawn a new shell, that does not have the env you just loaded? <mschilli>Because on my host system I do not run bash. <ecbrown>i need to get a doughnut, i will let you try my suggestion verbatim :-) <ecbrown>i don't think the shell matters -- in fact i have done it with zsh <mschilli>I did try with your exact suggestion as well. <mschilli>I'm getting yet another clone to make sure all is clean. <mschilli>Do you really want me to not use --pure either? <mschilli>Thought that should make debugging easier. ;-) <ecbrown>well, i would try it without, first. <ecbrown>you certainly like the cutting edge lol <mschilli>I use Guix to reproduce my environment on systems I don't have root access to. ;-) <ecbrown>mschilli: yes, i funneled in to this space via pkgsrc unpriveleged <ecbrown>well, i'm not sure... hopefully there's enough evidence here that someone else can spot the issue. <mschilli>Is there a way to skip building the docs? If the error hits a non-essential part of the build, maybe I can ignore it. ;-) <ecbrown>i think you can, but those are usually just warnings <mschilli>ecbrown: Thx anyways and enjoy your pastry. :-) <chaos`>nckx: (rewriting the .iso image to the usb solved my problem. Thanks!) <pkill9>mschilli: do you install guix without root access? <mschilli>pkill9: I have a system-wide Guix instance, daemon, and store provided on the host. <rekado_>(we should document how to deploy Guix without root privileges with just ‘guix pack‘) <mschilli>For strictly non-root systems, I generate containers using Guix on a system that has it, copy the container, and run commands from therin on the target. <mschilli>rekado_:Hi! I assume you'd still need /gnu on the target system, no? <mschilli>I'd be very much interested in a solution giving me full Guix on a remote system I don't have root permissions on. ;-) <mschilli>I'll leave for a run hoping for someone to have an idea by the time I am back. ;-) <rekado_>mschilli: with "guix pack -RR" you unpack your Guix wherever you want <rekado_>and then *guix* itself runs in the container, using the remapped /gnu <apteryx>bricewge: the base is already working, but it'll need some polish (re .deb pack format) <apteryx>such as allowing the user to provide their own control file <ecbrown>The_tubular: the provenance errors are normal <ecbrown>if this is the first time you are updating maybe it needs to cook for a while <ecbrown>the second question is: do you have functioning networking on this computer? <apteryx>civodul, nckx, mbakke, mothacehe moin! the rendezvous point is up and running if you need to test your setup <The_tubular>Here's what I have, only thing to note is that I'm using WSL, but it should work ...? <civodul>apteryx: ah! i'm physically at work without my headphone and all so can't test right now <ecbrown>The_tubular: can you ping 1.1.1.1 from the terminal inside of wsl <ecbrown>ok, well that's a good first step. i dunno, maybe it's a wsl thing. found a gist on github about guix on wsl <The_tubular>Yeah, I followed one that has been linked here a few days ago <ecbrown>i mean, the error you are seeing is mentioned in that webpage <ecbrown>maybe you have to do that and then it will work <The_tubular>Does that act as some sort of firewall or something ? <ecbrown>yes, but more on the unix process side <The_tubular>Do I need to define every protocol I'm going to use manually ...? <ecbrown>yes every service has to be registered in /etc/services. it is not the firewall... some computers run without a firewall <ecbrown>it does not turn on a port to even listen <ecbrown>(i think you're approaching "unauthorized territory" for gnu channel) <ecbrown>i think this is about non-free system init, and it may not be proper to assist efforts on a gnu channel <ecbrown>well, it goes on to the next issues, and those involve nonfree init if i understand correctly ***soheil_ is now known as soheil
<soheil>Friends, are Flatpak/Flathub software free? <TheAsdfMan>guix pull: error: Git error: unexpected http status code: 504 <ecbrown>soheil: if the package is in guix it's virtually a guarantee. it's not a gurantee that every conceivable flathub project is free <ixmpp>Oh no, 504 is gateway timeout ***soheil__ is now known as soheil
<yoctocell>how do i know what archive to use when invoking `guix import texlive --archive=ARCHIVE foo'? <sneek>Welcome back yoctocell, you have 2 messages! <sneek>yoctocell, apteryx says: thank you! I've been meaning to try it/comment on it, but haven't gotten around it yet. <mschilli>rekado: I see. I remember trying this. My target system does not support user namespaces and the proot solution did not work either. <mschilli>I don't recall if I could not get proot to install without root but I think it just segfaulted and I gave up eventually. <mschilli>The fakechroot option is new to me. You know if it would work on GlusterFS? <mschilli>And how come I cannot make Guix in a `guix environment guix`? Isn't that the whole point of Guix? ;-) ***soheil_ is now known as soheil
<ecbrown>mschilli: you need a nice trisquel base ;-) <ecbrown>i heard andrew lee took over savannah <zacchae[m]>I included a `(service gdm-service-type)` but I get a TTY on boot. Is this normal? If so, how do I launch X? (first guix install) <zacchae[m]> * I included a `(service gdm-service-type)` in my config.scm, but I get a TTY on boot. Is this normal? If so, how do I launch X? (first guix install) <ss2>zacchae[m]: Did you use the installer? Did you not select a destkop environment? <ss2>as far as I know, the installer will set up gdm for you, should you select any of the environments presented at you. <zacchae[m]>ss2: you mean include them in the list of packages? Then yes. I have: `dmenu emacs emacs-desktop-environment emacs-exwm i3-wm i3status' <zacchae[m]> * ss2: you mean include them in the list of packages? Then yes. I have: `dmenu emacs emacs-desktop-environment emacs-exwm i3-wm i3status` <zacchae[m]>or is there some other thing that must be specified? ***soheil_ is now known as soheil
<ecbrown>damn i just switched everything over to my personal guix <rekado_>mschilli_: yes, “guix environment guix” should be enough. What you reported earlier sounds like someone broke the documentation. <mschilli_>rekado_: So I could try to git bisect this then later. ***soheil_ is now known as soheil
<zacchae[m]>ss2: I see one subtle difference that I'm trying now. Thanks <asterope>I'm using the install iso from usb to install guix on a laptop where efi is out of the question, but each time I get booted into grub recovery shell <asterope>I can see that on the disk there's a /boot/grub dir, but in the recovery shell /boot is empty <asterope>does anybody know why would this happen? I searched for a few days already <vagrantc>ok, got a different NVMe for the pinebook-pro and it boots normally from u-boot ... no special dance <vagrantc>not exactly loving the "swap out NVMe until you find one that works" troubleshooting process ... <dstolfa>vagrantc: do you think that a pinebook is a good carry around mini notebook? <vagrantc>pinebook is realyl slow, pinebook-pro is not bad <vagrantc>but "good" ... that's a really brod-sweeping question :) <vagrantc>still haven't found source for the keyboard firmware, which is a bit disconcerting <dstolfa>well, suppose you have to travel and you at most need email, telegram and a pdf viewer for presentations <vagrantc>i've gotten it to run graphically with sway ... can't imagine email being a problem, but then i use console-based email clients <vagrantc>never used telegram, but don't think it's too heavy <dstolfa>ah, so plugging it into a projector is a no go <vagrantc>the substitute availability for aarch64 is still not great <dstolfa>vagrantc: i'd probably have my own build server for that if i were to get a pinebook pro <rekado_>I’m still waiting for the three server boards I ordered a while ago <vagrantc>though work is in progress to improve availability for aarch64 <rekado_>(today I ordered the other stuff, which I delayed so I don’t sit on hardware without mainboards) <vagrantc>dstolfa: i suspect wifi likely won't work with linux-libre, etc ... <vagrantc>rekado_: curious how the honeycomb boards work out <dstolfa>vagrantc: that's okay, i have ath9k_htc adapters on the ready <vagrantc>i'm not impressed with the hifive unmatched speed wise, though just got an NVMe installed, maybe that will make all the difference (vs. microSD) <efraim>I like my pinebook pro like I liked my x120e. Amazing as a netbook style "+1 device" or "travel device" but definately not a main device <efraim>vagrantc: building gnutls28 from source to build with guile-3.0 bindings took 28 minutes on powerpc and 118 on riscv64 <vagrantc>luckily, the NVMe that didn't work on the pinebook-pro appears to work fine in the hifive unmatched :) <vagrantc>efraim: how long did it take you to build guix on the hifive unmatched? <efraim>I have a 256GB NVMe that I bought a year ago, I'm still waiting for a good time to disassemble my ibook g4 to replace the hdd <vagrantc>the ~5 hour build times makes me worry about guix pull <efraim>vagrantc: IIRC it was about 3 hours on ubuntu with -j3, closer to 5 hours on Debian, both of those with make, not building a .deb <efraim>at least it doesn't start hitting swap like it does on 32-bit powerpc. Dropping the optimization level that civodul did a bit ago dropped the guix compile time from 16 hours to about 6 <vagrantc>yeah, ram is the main thing the unmatched has going for it :) <vagrantc>i did my entire build in tmpfs ... which is why i don't expect the NVMe to make a lot of difference <HiddenKarma>I'm trying to create pre-inst-env script from the Guix build tree but there's an error when I run bootstrap: macros PKG_CHECK_MODULES, GUILE_* are possibly undefined <efraim>I did the first year or so of aarch64 package fixings with constant building on an sd card and an external harddrive <vagrantc>dstolfa: also of note, i haven't had the pinebook-pro working during any timespan in which travel was a thing :) <efraim>Mine is still running manjaro, looks like a full charge (without NVMe) and light usage should be about 10 hours of battery life <efraim>probably closer to 4 or 5 if compiling at the same time *dstolfa wishes he wasn't a poor student so he can buy one... in a few months perhaps :) <vagrantc>i've definitely run down the battery on the pinebook-pro even while plugged in to power <vagrantc>mainly running: guix pull && guix build linux-libre ... <dstolfa>so the pinebook pro uses more power than the charger can provide? <efraim>If/when I switch it over I'll probably pin the kernel with an inferior or build it on my regular pine64 <efraim>the included charger provides 15 watts, 5 volts at 3 amps <vagrantc>i've never seen it able to draw more than 10watts from the provided charger <efraim>it can sit in the corner and just build things until its done :) <vagrantc>dstolfa: it's also spike loads ... it doesn't always draw that much power <vagrantc>but yeah, you'd think it wouldn't drain the battery while plugged into a power supply :/ <efraim>sitting around chatting with system load under 1 I'm drawing 3.69 watts from the battery <efraim>my old x120e that I used as a travel laptop never dropped below 7, and that was hands off the keyboard and display dimmed really low <urawn>so, I figured out I'll need grub-efi-bootloader, but I haven't figured out how to specify 'mapped-device' to use a keyfile together with luks-device-mapping <urawn>I guess my only alternative for now is doing things by hand, everytime the system updates... I'll see if I can contribute with what is needed to make this natively possible <vagrantc>what triggers inode de-duplication of /gnu/store ? <vagrantc>notably, can i trigger it manually? i have ~14GB of stuff that i'm pretty sure only takes about 6GB with deduplication <vagrantc>i ended up rsync'ing the pinebook-pro filesystem from the not-so-happy NVMe to the new seemingly-happy NVMe ... but forgot to pass the hardlink flags <iskarian>building gcc with --system is... painful ***soheil_ is now known as soheil
<iskarian>What do you all think about a --with-tests option? <apteryx>what do you mean? there's already a --without-tests transformation available <iskarian>A very few packages have tests but they are disabled by default, it would be slightly easier to use `--with-tests` than make a new package just to add `#:tests? :t` <iskarian>To be fair, usually there is some other work required to make tests work, such as adding native inputs, which AFAIK you can't do with command line flags <efraim>vagrantc: do you know what might be causing this error with diffutils-boot0? <efraim>make: /gnu/store/0bxdn94rl7fvqksgf60vffsjn6h8fky8-bootstrap-binaries-0/bin/bash: No child processes <efraim>make: /gnu/store/0bxdn94rl7fvqksgf60vffsjn6h8fky8-bootstrap-binaries-0/bin/bash: No such file or directory <efraim>I don't have any problems with running guix-daemon using ./pre-inst-env on other architectures <efraim>and is that where you're getting stuck? <apteryx>one 'guix pack -f deb' current limitation: you can only install one such package at a time, otherwise they conflict. Solutions are: 1) -RR with a unique install prefix (chosen automatically?) 2) one deb per dependency. Option 2 is really cool but doesn't really fit the current 'guix pack' model. <apteryx>longer term we could imagine option 2 directly populating the metadata files of an apt repository with the various single .deb archives. The whole of Guix collection available for apt users! ***stikonas_ is now known as stikonas
<itismyfirstday>However, I did change native-inputs to be the already existing cabal-doctest package, and can see in the build that the GHC package directories includes the one for cabal-doctest, yet still doesn't see it for some reason <rekado_>somebody changed some Python packages to use python-distlib/next instead of python-distlib. <jackhill>Has anyone else observed periodic crashes with sway? I am, but not sure how much energy I want to put into investigating since I see there is a sway/wlroots/wayland update on core-updates. <rekado_>commit ce6efff6eca0ed88cb9538803f5d1252c91a3b5e is the culprit <vagrantc>apteryx: interestingly i've pondered turning .deb packages into lazy /gnu/store items :) <vagrantc>efraim: make: /gnu/store/0bxdn94rl7fvqksgf60vffsjn6h8fky8-bootstrap-binaries-0/bin/sh: No child processes <vagrantc>oh, there are some bash too ... make: /gnu/store/0bxdn94rl7fvqksgf60vffsjn6h8fky8-bootstrap-binaries-0/bin/bash: No such file or directory <vagrantc>make: *** [/tmp/guix-build-diffutils-boot0-3.7.drv-0/GmvcS7mA:1766: .deps/alloca.Po] Error 127 <efraim>I wonder if it's a bug in the bootstrap binaries or something else <efraim>5.4.20 shouldn't be too old for riscv64, right? <vagrantc>i suspect it's /bin/bash is calling some file that isn;t there *vagrantc looks forward to the promized parallel xz options in core-updates <nckx>chaos`: Yay, and thanks for letting me know! I always wonder how people I never heard back from fared. <nckx>jackhill: I use Sway and haven't noticed visible crashes, but my clipboard is unreliable and I get the following logged a handful of times a day: <nckx>smithay-clipboa[801]: segfault at 21 ip 0000720f18ddb8e3 sp 0000720f107075e8 error 6 cpu 3 in libwayland-client.so.0.3.0[720f18dd7000+5000] <nckx>I'd guess that's from Alacritty. <apteryx>is it possible to share a directory using GNOME Boxes? <jackhill>nckx: weird. At first it really seemed like ungoogled-chromium-wayland was causing it, so I switched to the X11 version, but the last couple of times not chromium was running at all. Fingers crossed that it's fixed in core-updates :) <apteryx>there's a "Devices & Shares" tab in a VM properties, but I see no way to configure "Shares" <nckx>Smithay… is a Rust thing so it could be IceCat, I guess. <nckx>(Also judging by all search results GNOME is black now wtf?) <jackhill>"I don't always use chromium, but when I do, I crash my compositor" would be a catchy tag like I think :þ <nckx>Each crash is GPU-accelerated. 👍 <nckx>We're obviously missing some kind of library/environment magic. *nckx whispers raghavgururajan's name on the wind. <itismyfirstday>digging more into the Haskell cabal-doctest issue, might be because these packages use a "setup-custom" which isn't supported? <apteryx>is it possible to query the freedesktop icon database? <vagrantc>efraim: i also tried building with --cores=1 --max-jobs=4 ... and i also get a similar failure for file-boot0 <ytc>hello. my mouse cursor theme changes when i move it across different programs. how can i solve this? *dstolfa has reached the 10 day point where guix starts complaining that my system is too old <cbaines>there's not a downloadable aarch64-linux installer image right? but I assume one can be built? <vagrantc>cbaines: not sure what it would take to build one that works reliably ... you'd need a complicated initrd-modules section <apteryx>cbaines: I assume so! It should be in the manual, else you could look at our Makefile.am file to see how we make it for the release <cbaines>I'm running guix system image --system=aarch64-linux -t iso9660 gnu/system/install.scm at the moment... <cbaines>I'm sure I re-installed Guix on monokuma (an Overdrive) via a USB installer, but I can't remember the details <apteryx>won't guix's openssl consults certs under /etc/ssl/certs on a foreign distro? <vagrantc>cbaines: i've toyed with the idea of generating a debian live image with guix preinstalled... <ixmpp>I think it's kernel panicking? <ixmpp>Just going by responsiveness <cbaines>vagrantc, I've often taken that approach. I'm probably going to try installing Guix on this system via Ubuntu. I can't get it to power on with the nVME drive installed though :/ <apteryx>seems our openssl only looks at its configured --openssldir (a subdirectory of its gnu store location) for certs, else SSL_CERT_DIR <apteryx>which means people are forced to install nss-certs and have openssl installed to make it usable on foreign distributions <rekado_>apteryx: is this a problem? It’s covered at length in the manual. <apteryx>it's kind of suprising when you use an application that relies on openssl without the user being necessarily aware of it. For 'guix pack' it also forces me to come up with some wrapper so that the can be sourced to get the correct variables. <apteryx>e.g., if you 'guix pack jami-qt' and run it on a foreign distribution, the search won't work, nor will registering a username with the name server. <apteryx>even if the foreign distribution has usable certs under /etc/ssl/certs. I wonder if some kind of fall-back could be possible/desirable. <apteryx>I've seen this done a couple places in Nix <apteryx>rekado_: nix has a patch for it! use-etc-ssl-certs.patch <raghavgururajan>nckx leoprikler bricewge: Sorry, I fell asleep. I'll check on suggestions. <apteryx>seems like good material for core-updates; what do you think? <rekado_>with that patch can we still overwrite the cert bundle with SSL_CERT_DIR? <rekado_>(or whatever the variable is called) <rekado_>FWIW this default location would not work on RHEL. It’s /etc/ssl/certs/ca-bundle.crt there. <nckx>raghavgururajan: You mustn't apologise for basic human needs. <solene>any dino users? Latest version makes dino using a lot of CPU when doing nothing <apteryx>rekado_: I think the SSL_CERT_DIR has precedence yes (to be verified) <raghavgururajan>nckx: I asked something and didn't respond to the response for long-time. :) <Mordo>I'm having trouble building Guix from Git, running ./bootstrap gets the undefined macro PKG_CHECK_MODULE error. <solene>Mordo: on Guix or another linux distribution? <nckx>Mordo: Are you in a ‘guix environment guix’? Or, if you don't have Guix installed yet, you have to install all prerequesites through your distro's package manager. <solene>Mordo: if you follow the insutrctions it should work, I did it recently <apteryx>rekado_: re RHEL. OK. Still better to have a default that works 75% of the time than 0% :-). <solene>what is the difference between "git pull && ./pre-inst-env guix upgrade" and "guix pull" ? <cbaines>the first one will upgrade packages using a Git checkout of Guix, the second will update Guix in the users current-guix profile <vagrantc>pre-inst-env can also sometimes get into a messy state in various ways, and you may have to re-run the ./bootstrap && ./configure ... stuff <solene>is the first way acorrect to update? <vagrantc>using pre-inst-env is generally faster as it doesn't have to rebuild everything ... and should usually be ok ... usually :/ <nckx>solene: Both are correct, they just apply to different situations/wishes. <nckx>The same ‘&& guix upgrade …’ after ‘guix pull’ being implied. <Mordo>solene: The thing is, I'm trying to test a package I made, and when I read the manual, I'm not sure how to properly test it using "guix environment" <Mordo>I've already cloned the Guix tree and added a package definition to a scheme file, how do I create an environment using this modified tree? <jonsger>can others build vtk on current master? 
