<civodul>janneke: i made some progress on system cross-compilation on master <civodul>but i was trying to do several things at once, finished half of each, and so that's it <rekado>tsmish[m]: it would also be good to include documentation changes; that way it’s easier for reviewers to tell what the code intends to do and to see if it actually accomplishes that. <civodul>janneke: but with the fix from earlier today and the vm.scm fixes we discussed earlier, it seems to be better <rekado>civodul: spent the whole day doing about 1% of everything at once <civodul>rekado: yeah it's very good initially because you feel energized and all <civodul>but at the end of the day, it's super frustrating <kamil_>I'll be going. I seem to have the qemu-minimal being stuck on the check phase problem again, but I've already spent too much time troubleshooting stuff, and I'm getting asleep. Thanks everyone for pointing me in the right directions. Bye! <ruffni>kamil_ do you have enough free disk space? <kamil_>I'll be back someday.. under a different name--this one is not my usual one. <codemac>does anyone use libreoffice with guix, but not guixsd? It opens up a dialog box with all utf boxes, and then closes <pkill9>what does it say in the terminal output? <rekado>codemac: could it be due to XDG_* variables? <codemac>terminal output just says "User installation could not be completed" <codemac>It looks like it can't find fonts either <codemac>I think it's due to fontconfig based on strace, but that may be a red herring due to the volume of syscalls <codemac>yeah, just decoded the error dialog that it presented the unicode boxes (which were all 0065 etc), it's the same user installation erro <codemac>ok I think it has to do with fontconfig on the host system that has $HOME/.fonts stuff vs. the fontconfig libreoffice is using <tsmish[m]>rndd: mindustry by any chance? Not that I solved it properly. <rndd>you triend any way to run it? <tsmish[m]>rndd: I hacked LD_PRELOAD_PATH. It leaves so files, so you can ldd them and find what they need. Also you can try packaging it or asking someone to package it, but it uses gradle and I heard horror stories about packaging java. <tsmish[m]>Also, discord is proprietary and should be erased from it, but you'll actually need to rebuild it and I didn't manage to. <rndd>tsmish[m]: anyway thanks <rndd>raghavgururajan: you can check mastodon <xelxebar>When editing a file in the repo and running make, I always see "note: source file <foo.scm> newer than compiled <foo.go>" output twice in a row. <luishq>Hi everyone. I'm a new guix user. I first heard about guix from ambrevar's blog posts and they got me really exited. Yesterday I took the jump and have moved from arch to guix. Now I'm working on reading the entire manual and figuring out how to set things up. Happy to meet you all. <luis->hi im the same person--LuisHQ. I do everything in emacs so I've just tried signing in through the circe emacs package. I'll quit my LuisHQ signin now. <luis->Oh there is something I did want to mention. I tried installing guix about 3 or 4 times before succeeding. I used the graphical installer. When I'd try to connect to wifi the graphic installer would be come non-responsive. <luis->I succeded in installing guix when I used an ethernet cable. <bavier>luis-: sorry, I believe that's a known issue with the 1.1.0 gui installer <bavier>I don't know if there are plans to cut a 1.1.1 to fix that or not <luis->And nice to meet you bavier :) <carlosgonz>I have several day trying to install guix in my computer into a nvme, but the guix installer not show me the nvme disc to burn it. <bavier>carlosgonz: I've not used nvme disks before. Do you know if there is a kernel module that needs loading before the installer can see it? <carlosgonz>I can not see it, do you know how? I had Libre/debian 10 running good in my nvme disk, now I want upgrade to Guix. <rndd>xelxebar: ye, i thought it is important to note <xelxebar>carlosgonz: Do you see the `nvme' module in the output of lsmod? <rndd>xelxebar: wrong link in licences <xelxebar>rndd: You could try submitting a patch, I guess? <rndd>xelxebar: could you note where licences defined is source code? <carlosgonz>xelxebar: I am new to Guix, not sure how to use lsmod. I am using Coreboot-seabios too, so maybe seabios would be blocking the installation?? <xelxebar>carlosgonz: lsmod is just a command line tool. It will list the currently loaded modules and their dependencies etc. <bavier>rndd: most licenses are defined in guix/licenses.scm <xelxebar>If you see nvme in the left hand column, then the module is currently loaded <xelxebar>rndd: Yeah, as bavier says. But in general, grepping the source is a pretty good way to start getting familiar with where things are. After playing around a bit, you should start to develop an intuition of where to look. :) <carlosgonz>I did lot testing I put a ssd then ssd is showed SOMETIME mostly Guix-installer returns to the beginning when the section to choose a disk arrives <xelxebar>carlosgonz: Generally, there are a few different levels at which things can go wrong with drives. First, check to see if the kernel notices that anything is plugged in at all by grepping for likely things in the output of dmesg. <xelxebar>If nothing shows up there, then the kernel doesn't see your drive at all and the issue is probably bios (or hardware). <xelxebar>If dmesg output contains something that looks like it's seeing an nvme drive, then the issue might be a missing kernel module. lsmod shows you a list of loaded modules. modprobe lets you insert new modules (in this case "nvme"). <xelxebar>If the module is loaded and things are still not working, try looking at the output of lsblk, to make sure the drive is loaded as a block device. lsblk basically shows you which "drives" exist and their partitions. <xelxebar>If you see your drive there and things *still* don't work, then I'd start suspecting the installer <carlosgonz>I customized my computer to use it with libre-software so I burned coreboot-seabios ATM because it has nvme support. so now I want get run Guix-mate. Right now I upgrading coreboot together seabios. I will come back tomorrow to asking more details. <xelxebar>carlosgonz: You sure that coreboot was the issue? It's possible for the kernel to see your drive without it showing up in /dev. <carlosgonz>Not sure if coreboot or seabios was a issue to install guix, I will come back tomorrow here with more details what is happening. <carlosgonz>I feel too that Guix installer still is unstable. <xelxebar>carlosgonz: I mean, you are sure that the problem is one either coreboot or seabios an not something farther upstream? <carlosgonz>In other computer with private-bios the Guix-Installer work better : ) i got install guix in a ssd as well but this install was for testing. <kolyad>I have a btrfs subvol for var, should I mark it as needed-for-boot? <apteryx>kolyad: if it lies where it needs to be used (/var) no need to even mount it. <apteryx>it will be visible when your root / is mounted. <poet>I haven't used guix for a while, so tonight I'm upgrading my system. I did 'guix pull' and now I'm running 'guix package -u'. Is this correct, and is there anything else I should do? <poet>This is my notebook. I'm the only user. <poet>Oh, I need to run it for root too? Okay, I didn't know that. Thank you. <srandom>After running, you can restart guix-deamon. <poet>That's done with 'systemctl restart guix-daemon.service' right? <poet>(I'm on a foreign distro btw. Debian) <kolyad>after unmounting the var subv, there are important directories in var (on root subv) still, so I'll just use var on the root subv for /var and re-init. <yyyyyy>I am having a bit of trouble. I have been using stumpwm + emacs + icecat for about all of my work, but I just installed LXDE and noticed many applications cannot find my fonts. I think it is limited to GTK applications (lxappearance, menus in LXDE, LXDE's calandar, etc). Does anyone have any ideas about why this would be? When I run fc-list it finds my fonts. <ryanprior>yyyyyy: I installed fcitx and it can't find my fonts either, it shows a bunch of tofu blocks X.X <bav[m]>peanutbutterandc: it just failed to build for me too <bav[m]>peanutbutterandc: I think maybe termbin didn't get the tail end of your log? <bav[m]>I get an "invalid conversion" error <peanutbutterandc>bav[m], No sir, it seems I don't have that error at the end for some reason (I am on a foreign distro, BTW) <bav[m]>My guix is a bit older, I'll `guix pull` and try again <bav[m]>runtime things sometimes behave different from on foreign distro, but build things should be reproducible <peanutbutterandc>aww... it seems all the cool kids are on guixsd and I'm the only foreigner around here <bav[m]>there are quite a few people running on foreign systems; it's just not something that's frequently brought up <bav[m]>but Guix System is pretty nice :) <peanutbutterandc>bav[m], Yeah... But I for one have decided to stick to foreign distros. That way I could report all the foreign issues... I've been having a few of those these days <peanutbutterandc>bav[m], It's my pleasure! Did manage to get a small installation patch in too. But guix is super fun. :) <ryanprior>I use Guix on elementary OS. I'm slowly working on porting its Pantheon desktop environment to Guix =D <bav[m]>peanutbutterandc: same/similar "invalid conversion" error with latest guix on my side <peanutbutterandc>ryanprior, Hey! Have you had any issues with emacs and guitarix on Elementary OS? *bav[m] wondering whether to keep a vm to debug such issues <yyyyyy>My fonts issue from earlier is confirmed GTK specific. QT applications are fine. <ryanprior>I'm gonna try and build it just to see what happens <ryanprior>../src/LV2/gx_amp_stereo.lv2/gxamp_stereo_gui.cpp:237:1: error: invalid conversion from ‘void* <ryanprior>I'm on Guix ad81708d2230af547e513a5bc8a69f70afa72b3c <peanutbutterandc>yyyyyy, I had a similar issue with fonts once (on my foreign distro) and I had to switch generations back as a work-around... so I feel you <peanutbutterandc>ryanprior, Thank you. I am glad that it fails for others too. As long as the issue is reproducible, I'm happy. (Except, we do have slightly different logs, but oh well) <ryanprior>Are you working on updating/fixing the guitarix package? Or just trying to get it to work? <peanutbutterandc>ryanprior, just trying to get it to work.... actually, just trying to upgrade it <bav[m]>I don't see anything related in the upstream bugtrackers <srandom>Will guix support multi-thread download in the future? <srandom>The single connection to ci.guix.gnu.org in my area is too slow. <bav[m]>there's been some good progress lately to better support that eventually <srandom>Thanks for the work of the developers, looking forward to this feature. <ryanprior>BitTorrent for downloads would be awesome too. I would seed all the time. <ssb>hi! trying to wrap my head about guix... installed it from source on a foreign system, launched "guix pull --dry-run" -- now it is downloading openldap from www.openldap.org. Why? <lle-bout>I would seed too, I got so much bandwidth <lle-bout>ssb: GNU Guix has substitutes that include pre-compiled software from GNU Guix recipes, however, when GNU Guix recipes are compiled down to a binary subtitute, they can download source code from many sources, usually it starts with upstream and then tries other mirrors. All imported external resources are cryptographically hashed so that's secure. If you care about privacy during build probably you should use Tor or something for all <lle-bout>There's also the project Software Heritage that aims to create a mirror of all software included in GNU Guix or Nix <bavier>ssb: if you're looking for substitutes, you'll need to authorize them first. <ssb>is --dry-run misplaced there? <ssb>(I wanted to perform dry run check before launching heavy operations on this laptop) <bavier>ssb: maybe try also with --no-grafts <bavier>well, I think maybe that is implied by --dry-run <ssb>authorize worked, thanks! (now it is downloading stuff from ci.guix.gnu.org), but what --dru-run actually means there and if or how it is supposed to work is completely unobvious <ssb>must be a bug, because it contradicts docs <civodul>apteryx: the sesquicolon is a clever trick! <mothacehe>hey civodul! Thanks for fixing the cross-compilation issue :) ***wxie1 is now known as wxie
<janneke>civodul: i updated and reset wip-hurd-vm to an even more minimal set <civodul>i think you can install the sockaddr-in patch on master <janneke>it seems you fixed the cross build too well -- system vm-image wants to cross build glib --so prolly qemu (meson build system barfage) <civodul>i have vm.scm changes here but i didn't finish it "on time" yesterday :-) <janneke>...youpi applied my hurd xattr patch! <janneke>so...i'm dabbling with xfstests for the linux patch <janneke>i don't expect anything, but i'm a noob there and apparently it's required before submitting an fs/ext4 patch--so *janneke has been removing /usr/bin/* all morning and tearing hair <janneke>civodul: so...when #+ is ready...we may have a full hurd-vm soon <civodul>i thought there were zero tests for Linux, but it's actually not that bad :-) <janneke>why write tests when you have users? <rekado_>xelxebar: that message tells you that Guile will use the slower interpreter on the uncompiled newer file. You should run make to compile your modified Guix. ***rekado_ is now known as rekado
<rekado>I’m surprised that I seem to be the only one to use the comment feature on issues.guix.gnu.org <rekado>I didn’t mean to eat the dog food all by myself :) ***poet` is now known as poet
<ssb>how do I "chroot" into a freshly built system (with guix system init) and work from there? *rekado investigates slow downloads from ci.guix.gnu.org ***sputny1 is now known as sputny
<lle-bout>rekado: ah you get them too now? It's been OK for me now. <lle-bout>janneke: how can I run GNU Hurd now that it's been merged? <janneke>lle-bout: the Hurd work has not been merged, really <janneke>we're working on the wip-hurd-vm, that is currently broken <rekado>lle-bout: no, I don’t suffer from bad connections, but I think it’s odd that the download speed seems to hit a limit at about 2MiB/s on average. <rekado>I would expect something better, given that we have dual 10G links. <janneke>there are hacky, prototype'y branches on my gitlab -- if you really want you can try "wip-hurd-full-stack11" <janneke>lle-bout: the hurd vm work needed a number of very tricky cross build bugs to be found and fixed <lle-bout>rekado: oh yes! well part of that maybe is the client implementation? <lle-bout>Using HTTP2 there's huge chances that you can download everything in parallel <rekado>lle-bout: I’m thinking it might be switch misconfiguration <lle-bout>but in general, the only way to get full speed is having lots of mirrors and getting data from them all concurrently. Like BitTorrent or IPFS <lle-bout>because there's lots of peering issues around the work <lle-bout>rekado: yep, maybe something's being lossy somewhere, also the upstream may not actually provide 10G? <rekado>yeah, I’m thinking that some of the 10G uplinks are actually configured to 1G… <lle-bout>rekado: even with 1G it should be better than 2MB/s <lle-bout>janneke: ah ok, in the blog post it says it's merged <lle-bout>it feels weird that the core-updates branch has disappeared :D <janneke>lle-bout: right, of course: you should be able to do "./pre-inst-env guix build -f gnu/system/hurd.scm" <jonsger>can I add arbitrary tags to debbugs or only one out of a list? <rekado>jonsger: you can only provide arbitrary *user* tags <rekado>they are tied to an email address <rekado>so you can say “list issues that jonsger things are ‘meh’”, but there will be no global “meh” tag. <rekado>so… turns out that our 2x 10G switch uplinks are connected to 2x 1G ports on the datacentre switches <rekado>let me run against a wall for a bit, because head -> desk won’t do <rekado>I guess the good news is that things will be better soon. <lle-bout>is there 10G switches in the datacenter? <lle-bout>I can't wait to pull down the entire GNU Guix substitute archive in under an hour <lle-bout>I got 5Gbit/s download speed in practice at home, more or less <lle-bout>jonsger: local ISP in France called Free offers shared 10Gbit/s best effort subscription <abralek>oh my, I have 500/50 for 60EUR in NL <lle-bout>They stuffed the router with an SFP fiber port <lle-bout>Was there anything wrong with IPFS that it hasnt progressed much? It looked like such a great fit <lle-bout>It should be trivial to plug an IPFS daemon to the GNU Guix store <jonsger>rekado: but 2x1G is still 250MB/s so there have to be over 100 parallel connections that result in 2MB/s at once end <lle-bout>jonsger: yep.. for me there's something else but yeah <lle-bout>any reason why can't GNU Guix use libcurl GNU Guile bindings instead of the homegrown HTTP 1.1 implementation? <lle-bout>homegrown I mean, inside GNU Guile, AFAIK. <civodul>lle-bout: IPFS support is waiting for you to pick it up! :-) <lle-bout>civodul: OK! I'll try! if my GNU Guile skills allow me to <mroh>btw, ipfs: they have dropped http GET for the daemon in the latest version. civodul: would that break the wip-ipfs branch? <civodul>mroh: ah, could be, i haven't checked <xelxebar>rekado: About the warning that *.scm is newer than *.go, this displays when running make. <xelxebar>My question was why the message displays *twice* for every newer *.scm <alextee[m]>ls /gnu/store/cb233zll4xn9m9zjgsqhhmrvc64933dq-zstd-1.4.4 : bin share *alextee[m] sees the "lib" output with `guix edit` *alextee[m] goes back to hiding <xelxebar>alextee[m]: guix package also lists available outputs. Looks like there's a `static' one as well for zstd. <janneke># make sure this script returns success <rekado>xelxebar: they’ll disappear when make has run to completion <rekado>they are shown because compiling a file requires reading whatever it depends on, and those module files may be in need of compiling <xelxebar>rekado: I understand, but I see this message displayed *two times back to back* for every updated scm file when runing make. <rekado>that might be new; I don’t recall seeing this before <lle-bout>civodul: I just read the whole thread, sounds good you did much work already. So it seems there's rough edges in IPFS itself that make it troublesome, 2MB block size limit, lack of mature POSIX FS abstraction, .. I though these things would already exist by now since I used IPFS 3 years ago to browse and share files and it was working very great! Guess not! I'll think and try to do something.. I think there has to be something maybe <rekado>but still: 2MiB download speeds are suspiciously low, even at dual 1G <civodul>lle-bout: i think IPFS has a new "UnixFS" abstraction now that would be suitable <lle-bout>civodul: I just looked again it seems it's not released yet <rekado>we may also have to swap out the cables <rekado>somebody must have been in a rush *rekado looks left and right, then in the mirror <lle-bout>1G optical fiber shouldnt exist, or does it? <rekado>I don’t think we use fiber on this server <rekado>most of the cabling in the data centre is copper <rekado>for the cluster we use optical fiber <rekado>these little fiber terminators that you plug into the card are really expensive <rekado>(I guess it’s obvious I’m not a network guy) <lprndn>ryanprior: are you here? Just saw in the logs, you were working on porting elementaryOS stuff on Guix? It happens I'm currently doing the same... Maybe we can share our efforts? <pinoaffe>how can I see what changed in the dependency tree of a package between a known-good and a known-bad version? <lle-bout>rekado, civodul: I'm thinking the other reason for slow download speeds might be Hydra/Cuirass generation of nars on the fly being slow because GNU Guile would be? <rekado>lle-bout: we aren’t serving them on the fly <rekado>if they are not you get a 404 and we start baking <lle-bout>It's unfortunate you have to change format between disk and what's actually transfered <rekado>but maybe something’s wrong with our ngnix config <lle-bout>Maybe on the fly gzip compression from nginx serving the /gnu/store directly ? <civodul>rekado: BTW, the disk space situation goes according to plan so far: 3.0T right now <rekado>civodul: yes, it’s pretty stable <lle-bout>rekado: I can't see nginx config being an issue, how is disk I/O performance like? <lle-bout>You can probably install netdata to have real time monitoring of the server, it has a minimalist web dashboard by default that listens locally <lle-bout>It seems it's not packaged in GNU Guix yet <janneke>this xfs test suite is terrible, guesses hard-coded file names everywhere <janneke>can i run patch-shebang on a source tree...hmm, or should i try to create a package <nikita`>so i'm making first steps of progress of porting guix after my crude patch to guile. since older version of Nix in Guix wants argp header file, and Guix currently targets glibc (if ever anything else), is it a no-issue or should I add a check for argp to the configure.ac because I just ran into that <nikita`>iirc this is also in the gnulib, so idk which path to pick here. I chose a common argp implementation <nikita`>a check for the header file is justified imo <nikita`>building on NetBSD/amd64, with pkgsrc <nikita`>that's what my gnutls ticket was a last blocker for.. well is, but i locally patched guile <nikita`>in the long run adding native netbsd/amd64 support to guix <nikita`>depending on how receptive others are to the idea <nikita`>started packaging nix and guix for pkgsrc last year <nikita`>oh coll, next step c++ function prototype definition mismatches in the nix folder. tiny steps :D expect more patches coming from me in the future. I got Google Summer of Code soon, and also looking for a new job, but I'm sticking with this <kamil_>Hello everyone! I said I'd be back in days, but my plans have changed. *rolls eyes* Anyway! Can build phase be resumed after cancelling it? <nikita`>we could use linux binary emulation on NetBSD native, but that's not as challenging as making native builds :) <mbakke>kamil_: the build process must be started from scratch <mbakke>lle-bout: we do have Zabbix monitoring on the CI system, and had a bot that spammed this channel about disk space problems for a while *rekado will bring back the spambot if y’all don’t behave <mbakke>nikita`: does glibc work on NetBSD? <janneke> +bash: /root/xfstests-dev/tests/ext4/003: /bin/bash: bad interpreter: No such file or directory <janneke> +bash: /root/xfstests-dev/tests/ext4/003: Success <nikita`>mbakke: some features don't work, others do. I can build software against it in pksrc, but like nss doesn't fully work. I don't have a good informed answer. that's native. and linux emulation works differently. <nikita`>worst case, new libc to target. I still haven't done a full analysis, i wanted to do this once I'm past guix building <mbakke>nikita`: cool, that's promising :-) <nikita`>i think store path could get controversial ;) <civodul>mbakke: glibc upstream is only Linux + Hurd, and Debian has a port to the kernel of FreeBSD <nikita`>i think I'll have to argue for software installing stuff outside of pkg-prefix <nikita`>some software does this already, but for runtime service files <nikita`>usually everythjing goes wherever you defined pkg-prefix to be (/usr/pkg/ by default) <ssb>hi! is boot without initrd implemented? <nikita`>FreeBSD does away with many linux'isms in their kernel, which is probably one of the main reasons why this works. <janneke>mothacehe: it puzzles me less than yesterday, but i'm still a bit puzzled <janneke>i was "oh my, do i really have to dive into these *_64 bit syscall things?" *mbakke wants a *BSD port of Guix solely for building firewalls with 'pf' <mothacehe>janneke: yes I fear that the conclusion is that we have to use the 64 bits syscall version of stat, lstat & friends in mes, to fix the bootstrap build on NVME disks. <mothacehe>yes :( I'm still trying to confirm this, I'll let you know. <janneke>i have brw-rw---- 1 root disk 259, 1 Apr 15 22:21 /dev/nvme0n1p1 <janneke>built everything on my nvme...so the failure mode can be described more precisely <civodul>it's the 2nd bug brought to us by NVME disks <mbakke>ssb: did you try booting without initrd? it should work, though maybe not with the default configuration <janneke>so maybe (?, who knows such things?), it looks at <janneke>brw------- 1 root root 253, 0 Apr 15 22:21 /dev/mapper/guix <mothacehe>janneke: is your /gnu/store on the NVME disk? <srandom>Should (bootloader) and (file-systems) be optional fields? containers don't need it. <mothacehe>ok, so there's something more. You can try to build the C program I sent to see if fstat returns -EOVERFLOW. <mbakke>srandom: perhaps you can set them to #f? or the empty list for file-systems? <janneke>so, what's the idea behind this device number check? <janneke>it looks (to my untrained eye) entirely arbitrary <ssb>mbakke, not yet, trying to construct my first ever guix system on a foreign (debian) distro. I have my own kernel without initrd and modules which I want to use. If I'm reading gnu/build/linux-boot.scm correctly, then boot-system requires initird... <mbakke>ssb: oh, you may be right. I think some user reported that they were able to boot a kernel without CONFIG_MODULES, but I guess they still used the initrd. <nikita`>mbakke: depending on which direction and which BSD system to port to (NetBSD no longer uses pf) wouldn't that mean also porting hurd to that system or writing code to manage pf from guix? <janneke>mothacehe: so, i run: guix environment --ad-hoc --system=i686-linux gcc-toolchain@5 -- gcc -m32 mothacehe.c <mbakke>ssb: you can easily tweak, hack and test things with 'guix system vm' if you want to try stuff out without actually reinstalling <mbakke>nikita`: no pf? what does NetBSD use? it would just mean packaging the 'pfctl' utility and writing a rudimentary shepherd service <nikita`>npf, which is semantically close to pf but extends and iirc started on different approaches than pf <nikita`>our pf became rather neglected, I think dropped in 9? <mothacehe>janneke: yes, and could you strace it to have fstat return? <mbakke>right, I guess the canonical pf is full of OpenBSD-isms <janneke>"works for me" ... (but yeah, /dev/mapper/guix on /, which is 253, < 256) <mothacehe>janneke: ok. I'll try to confirm this theory on another machine with NVME disk. <ssb>mbakke, ok, thanks! Now I'm heading into scheme programming crash course ) <nikita`>no pf interops good enough I think? i ran into this when i wanted to port the part where gnunet uses iptables to *BSD. FreeBSD pf is not OpenBSD pf, etc <janneke>mothacehe: much appreciating your help <mbakke>nikita`: wowza, a BPF-based pf for Linux? /me will have to try it <nikita`>could be wrong, but at least i remember "some firewall porting issues" in gnunet, thanks that I can forget stuff and document <nikita`>all very early stages, but i think at this point we wouldn't have the resources (like Debian) to vendor a buildfarm for guix, but i first have to get there (I've seen the suggestion for Debian in the past to run their own substitutes server(s)).. so if I get this port to the point where it builds and then builds enough packages to satisfy usability, building from source for this would be acceptable <reepca`>hmm... to all users of call-with-container, on a scale of 1 to 10, how difficult would it be to change uses of it to eval-with-container? The upside would be that it would be safe in multi-threaded processes. *reepca` is pondering whether to replace call-with-container or keep it alongside eval-with-container <civodul>reepca`: you could try to make that change in Guix <civodul>eval/container is implemented in terms of call-with-container though :-) <civodul>mbakke: do we have a core-updates open? <reepca`>I didn't realize we had an eval/container. <civodul>there's no "eval-with-container", right? <mbakke>civodul: you'll have to create the branch anew, but please go ahead :-) <reepca`>an as-yet-unwritten one that uses open-pipe* + unshare to start a child guile process that puts itself in the desired container <reepca`>the interface would be less-than-pretty, especially for passing objects with no read syntax through <pkill9>I don't like how kdeconnect's daemon is in a libexec directory <civodul>reepca`: yeah like 'container-excursion*' <civodul>maybe it's better not to pretend objects can be passed around ***warp is now known as eta-expanse
***eta-expanse is now known as warp
***warp is now known as eta-expanse
***eta-expanse is now known as warp
<efraim>pkill9: agreed. I meant to move it last week but forgot about it <efraim>Or more rather the libexec dir is inside the lib dir, which is wrong <pkill9>efraim: kdeconnectd is expected to be in libexec though, if that' show it gets compiled <pkill9>maybe putting a symlink in the bin directory would be good enough <ruffni>i'm looking for some example configs for gdm and xorg-configuration.. i was trying to set autologin and the default resolution. i pasted the relevant section here https://paste.debian.net/1146819/ . i managed to get the config to pass the syntax test, but then gdm and/or xorg wouldn't start anymore... <ruffni>do i (append (list openssh-service-type) (...) (modify-services %desktop-services)) ? or should i explicitly replace the gdm definition in %desktop-services? <civodul>chrislck: did you try "fc-cache -fv"? <mothacehe>janneke: same error on another machine with an NVME disk. The '256' limit for the major node, is because the newstat syscall predates the transition of major nodes from 8 bits to 12 bits in 2.4 version. At that time, the stat64 syscall was introduced to handle 12 bits major nodes. <janneke>mothacehe: oh? so it should all work fine if only your linux kernel is newer than 2.3? <janneke>but "someone" is being extra-careful? <mothacehe>janneke: yes but nvme were not supported at that time I guess <janneke>i still fail to understand why this isn't a linux bug? <mothacehe> Over time, increases in the size of the stat structure have led to three succes‐ <mothacehe> sive versions of stat(): sys_stat() (slot __NR_oldstat), sys_newstat() (slot <mothacehe> __NR_stat), and sys_stat64() (slot __NR_stat64) on 32-bit platforms such as i386. <mothacehe> The first two versions were already present in Linux 1.0 (albeit with different <mothacehe> names); the last was added in Linux 2.4. Similar remarks apply for fstat() and <mothacehe>But yes, I don't get why NVME disks could not be handled like SCSI disks, just because they appeared after the 8 -> 12 bits major nodes transition <mothacehe>yes very. Trying to find kernel bug reports about that. <janneke>it could just be that we'd have to update the mes c library and all... <janneke>but it would be great to fully understand why that's a good solution <civodul>did you know that imported module (guix build utils) overrides core binding `delete'? <tsmish[m]>Does raid-mapping-device actually work? Looking at code, absolute paths to devices as targets wouldn't work because code compares filesystem paths to /dev/mapper/<target>. <civodul>i'm quite confident about the first part: it ensures the thing that runs in the VM refers to cross-compiled things <civodul>i'm less sure about the second part (choosing qemu) <civodul>why were we running qemu for the target in the first place? <civodul>i mean, we can build an ARM image in a x86_64 VM, can't we? <civodul>that is assuming that, say, x86_64 grub-install does the right thing for ARM <janneke>but before, it was "easier" to use target qemu <civodul>yeah dunno, we'll have to check with mothacehe <civodul>but maybe you can give it a spin for GNU/Hurd <janneke>the old solution "seemed to work" for some use cases <janneke>very happy to ... to the point of eager, hehe <pkill9>so has it been decided that build farms will provide a list of files contained in packages? <janneke>civodul: a first quick check, vm-image "hangs" for me *civodul looks a let-system, finds it good after all <janneke>on wip-hurd-vm, i added this revert: a523b6ff3d Revert "system: vm: Fix for cross-build to the Hurd." <civodul>and if you do a dry run, does it show "wrong" derivations? <janneke>i've been experimenting a hang this morning and parked it for later tonight <janneke>oh wait, --dru-run and --no-graphs shows something at least <janneke>hmm, with --no-grafts, libaio-0.3.112 gets built (and fails) for the hurd <civodul>well, except if we really need to run the target qemu, but i don't think that's the case *janneke undoes revert, and spends another $ => '#+(append (list parted e2fsprogs dosfstools) <mbakke>aw, substitute* can not work over multiple lines, I'll have to change my monster regex into an actual patch <ryanprior>sneek: later tell lprndn: so far I've got Granite, Appstream, Sideload, and Pantheon Terminal packaged. Of those, only Granite and Sideload are actually tested and working. <janneke>civodul: using --no-grafts, spending another few $ (that we'll have to look into!) but looking pretty nice <raingloom>has anyone used gajim's audio/video calls on Guix? my home server recently added support for it but the buttons are still greyed out. i couldn't find any relevant issues on the tracker, so maybe i'm just misunderstanding something. ***dingenskirchen1 is now known as dingenskirchen
<ryanprior>raingloom: nope but the Guix package for Gajim does kinda look hairy with regard to plugins, you might have to do something specific if the audio/video calls rely on a plugin. <janneke>so, we also need $+initrd, $+linux, $+( ... e2fsprogs parted ), which makes sense <janneke>if i don't comment-out bootcfg, a full grub gets cross-built, which is weird: bare-hurd.tmpl specifies a grub-minimal -- full grub does no build, so where does this come from <janneke>i'm using: ./pre-inst-env guix system vm-image --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl --no-grafts <janneke>and this now fails when building the vm, running qemu: wrong architecture for gnu/build/bootloader.go, gnu/build/utils.go, sqlite-3.go (the cross-built ones -- we need the native ones here) <janneke>i'll have a look later tonight if i can find out about bootcfg and these modules ... getting closer still :-) <ryanprior>What does it mean if a package has a source that comes from `mirror://gnome/sources/....` <ryanprior>What program do I run if I want to hash such a source? <NieDzejkob>wouldn't `guix download mirror://gnome/sources' work? <lfam>Those mirrors are defined in 'guix/download.scm' <lfam>You can copy a URL from there if you need to <ryanprior>Yep guix download worked, that's gonna be a timesaver =D <ryanprior>hype...........all my pantheon packages are actually working work <ryanprior>time to start cleaning them shits up to post on the ML <apteryx>ryanprior: that's pretty exciting :-) <apteryx>ryanprior: but please try to keep your language clean in the channel :-) <NieDzejkob>ryanprior: Want another timesaver? I recently learned about guix refresh -u $PACKAGE <nckx>Yeah, prefer ‘polishing poops’. <civodul>janneke: #+linux and #+initrd make sense <civodul>on master, with #+(bootloader-package bootloader), i don't see any cross-built GRUB <civodul>ah but i have another #+ patch in grub.scm <ryanprior>apteryx: thanks for sharing my excitement, I will adjust language :) <ryanprior>NieDzejkob: I am interested in building a web interface for `guix refresh` so I can keep an eye on new upstream releases for packages I care about <nckx>apteryx: IIRC you [wanted to] set up offloading with fall-back to local builds. Did that work? <apteryx>nckx: I moved on to other things. I should have at least logged an issue about it. It seems a valid use case. <nckx>apteryx: It is, I'm rebuilding stuff here & want it too. So that's a no? <ryanprior>What do you do if you have a bunch of outdated .go files in your guix source tree? <ryanprior>Should I use `find` to delete all the .go files and then run make again? Or is there something cleverer? <ryanprior>I did that, but now I'm running pre-inst-env commands and it's vomiting a thousand lines of ";;; In procedure load-thunk-from-memory: incompatible bytecode kind" <civodul>ryanprior: that's because you have Guile 2.2 .go files in $GUILE_LOAD_COMPILED_PATH and you're running 3.0 <ATuin>ryanprior: in those cases i rune the make clean but it takes a while to recompile everything again. I didn't find anything better :/ <ryanprior>civodul: I'm in a pure environment so hopefully my paths are set appropriately. I'm guessing that the guile 2.2 .go files are in my Guix source tree from when I had built it earlier. <nckx>ryanprior: ‘make clean-go’ runs the find command for you but you can imagine that it does something far more advanced if you like. <ryanprior>lmao okay clean-go it is, and I Will Be Firing Up Tha Imagination <apteryx>ryanprior: I had that too. You want to source your profile anew or re-login your graphical session. <apteryx>actually, just sourcing the profile will not get rid of the previous values, so you must re-login <apteryx>but if you are in an environment the --pure switch shoud give you a clean LOAD_PATH: guix environment guix --pure <ryanprior>Right, I am using --pure, so my profile shouldn't be intruding. <ryanprior>I'm 94% done recompiling after clean-go, so we will soon learn whether my skeleton army can defeat the forces of the flame lords and build a dark new world of guile 3.0 bytecodes. *nckx votes for ryanprior as future Guile code name chooser & release notes writer. <nckx>“Guile 3.3 ‘throne of blood’ brings some exciting bignum improvements.” <ryanprior>PERF FOR THE PERF GOD, MODULES FOR THE MODULE THRONE <janneke>civodul: ah...and i'm not on master, wip-hurd-vm rather <reepca`>I think I might be missing something... if I dup->fdes (current-output-port), I can use fdopen to get a port for it in the current process, but not in a child process. It says "invalid file descriptor". But I checked with (fcntl F_GETFL ...) and it doesn't have O_CLOEXEC set... *janneke looks at grub.scm <janneke>In procedure dynamic-link: file: "/gnu/store/rcjch7fa8q6yc8gfybq4bzkvx3wndi7f-sqlite-3.31.1/lib/libsqlite3", message: "file not found" <rndd>hi everyone! i tried usermod -aG docker myuser. but i still can run docker only as root. does i do something wrong? <apteryx>are you using the docker service on a Guix System? <chipb>rndd: your groups will not be updated for an existing session. you'll want to either logout/logon or e.g. 'su - yourusername' and run in that subshell until it's convenient to logout. <nckx>Side note: that's not a Guix-specific thing. <chipb>yeah, setgroups() is called by the [privileged] login program before it hands control over to your user. <rndd>chipb: i rebooted then and nothing changed <apteryx>rndd: but if you are on a Guix System (which I'm guessing you are, otherwise your docker service would be that of the foreign distro you're using). <apteryx>then it's best to add you user to that group in your operating system config <apteryx>that is, you add a "docker" entry to the 'supplementary-groups' field of your user-acount record. <rndd>apteryx: oh, you mead i need and my user in config.scm? <chipb>ah, indeed. I'm more a guix, not guixsd user. :-P <nckx>Yay, bcachefs-tools now depends on Rust. <nckx>Just another rabbit hole in which to sink my foot & break my ankle right before the finish line. <nckx>I don't know the first thing about Rust. <nckx>And since this thing has to be initrdified it's probably going to be fun. <nckx>Then again my initrd is currently 32 MiB compressed anyway 😛 <chipb>eh, surely it's just a build dependency? ***daviid is now known as Guest38350
<nckx>chipb: I dunno? See above for my knowledge of Rust. The new mount.bcachefs is written in Rust and wants something called cargo. ***Guest38350 is now known as daviid
<rndd>another question, guixsd use guix to pack guile libraries. racket uses it's raco. any plans to packet racket libs using guix? <ryanprior>rndd: you can absolutely package racket libs using guix if they are free software and useful to you. <ryanprior>rndd: unfortunately I don't see any racket packages yet to use as examples, we might need a pioneer X.X <chipb>nckx: huh. why does bcachefs even need a special mount tool? it's not a fuse filesystem is it? <ryanprior>Do racket libraries need a build system (is there a compilation step?) or do you just copy them into the right folder(s)? <nckx>chipb: Eh, it has something to do with being multi-device (like btrfs) AFAIK. Not having any multi-device bcachefsen yet I admit I haven't actually looked. <chipb>oh, interesting. I guess that makes sense. <nckx>Apparently systemd chokes on bcachefs's ‘:’ device separator, necessitating this new tool, so that's where we're at 😒 <nckx>jonsger: You got 5 somewhere. Where? <nckx>I'm sure of 3, I think we probably have 4, not sure about 5. <nckx>jonsger: That's where I got my data from, but I only count 4 - 1…? <nckx>That makes it imaginary. <civodul>if you're familiar with Racket, you're welcome to give it a try! <civodul>the other importers live in guix/import/*.scm <nckx>chipb: Anyway, bcachefs is a real boy^Wfile system in the kernel, just hasn't been merged yet. It's damned solid compared to btrfs at its age. Survived a few hard lockups (not bcachefs-related) without a peep. <nckx>To be clear by ‘damned solid’ I mean ‘only a handful of data-eating bugs a month reported’. File systems are hard. <raghavgururajan>nckx: I just saw your recent commits regarding updates. If you are still in that workflow, could you update dwm and/or st as well please? Thanks! <nckx>Eh, sure. Those are both packages I'm comfortable with (I don't update any random thing). <chipb>yeah, I'm vaguely aware of bcachefs but probably won't consider touching it until it's merged. <ryanprior>raghavgururajan: I've been working for a few weeks on getting a Pantheon desktop environment started in Guix, and today I polished and sent my first series of patches. I'd love it if you could review them! <raghavgururajan>nckx: Btw, since you are spacefm user, I wanted to let you know about xfe. I find it faster and lighter than spacefm. :-) <janneke>civodul: puzzles me how guile can be the native architecture, like qemu but its modules are cross-compiled <nckx>raghavgururajan: Interesting. Thanks! (Occasional spacefm user, only when forced to use a GUI.) <civodul>janneke: that's a semi-problem, and that happens with the patch i pasted earlier, but there are no extensions there <civodul>it's a semi-problem because it just means the .go files are ignored <janneke>doesn't it crash on the cross- sqlite3.so, that matches the cross .gos ? <raghavgururajan>nckx: Cool! When I checked with `top`, idle spacefm was using 0.6% of RAM, whereas, idle xfe was using 0.2% of RAM. <janneke>In procedure dynamic-link: file: "/gnu/store/rcjch7fa8q6yc8gfybq4bzkvx3wndi7f-sqlite-3.31.1/lib/libsqlite3", message: "file not found" <civodul>janneke: yes, with extensions, it's a problem: the cross extension cannot be dlopened <janneke>./pre-inst-env guix system vm-image --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl --no-grafts <janneke>that's inside the qemu vm, building the image *janneke tries to remove the sqlite extension+requirement <nckx>raghavgururajan: Here it uses 0.2%, so I guess you have 6-8 GiB of RAM. 🙂 Did you get your X200 back yet? <janneke>hmm, the store needs sqlite; guess with-extensions needs a target #f or so <nckx>raghavgururajan: dwm is already at 6.2 (newest)? <janneke>ah no, that brings us back to #:target #f on the builder and the manual (with-parameters ) hacking for everything that we put inside <nckx>Hullo anadon (and Blackbeard earlier). <nckx>ryanprior: Do you use emacs? <anadon>Heads up, I'm going to track through django 3 and dependent packages and enter them into the guix debbugs system so I can start to track what work is going to be needed. It is going to be messy, and a lot of them I'll close out after tracking down duplicates and existing dependencies. nckx civodul <nckx>Oh, are you Josh? How many are we talking about? <anadon>I am. I think on the order of 50. <nckx>Oh, OK. Fine by me personally. <nckx>Maybe do the dedup in a local document first? <nckx>But no strong feelings either way. <nckx>ryanprior: The indentation of your patches. If you've accepted Guix's indentation settings (! when emacs first prompts you in the repo), it should DTRT if you run C-M-q at the top of each package. <anadon>I can do that. I figured I'd let someone know, wait a few hours so it can propgate and give me some time to enjoy the great weather where I am, then commit some spam. <civodul>the cuirass log shows uncaught &evaluation-error <nckx>Without a hint of irony: do that. Enjoy. Smell the flowers & all that. Life is good. <ryanprior>nckx: I did accept the settings and I used C-M-q to get the current formatting. I assume something's busted? I eyeballed it too before submission & it looked right =X *janneke adds guile-target to gexp->derivation <janneke>it's so weird...guile itself is native, but its modules are cross <civodul>the sqlite database is portable across architectures i think <nckx>ryanprior: Never mind then, I think I'm looking at a (few days) old patch. Only thing that's busted in that case is my mail client. mu4e's been very… unpleasant lately ☹ Anyone else noticed strange things afoot? <civodul>janneke: in (guix scripts pack), there's 'store-database' <civodul>perhaps at some point we should use that when building system images too <nckx>Very slow, ‘silently’ snapping back to an old message in the view (so you end up looking at a different message than the one you hit return on), … <nckx>Especially fun when it does that 37ms before you hit ‘D’. <nckx>ryanprior: Your new patches are fine, disregard nckx. <civodul>janneke: but yeah, this whole load-in-linux-vm thing is confusing <civodul>we should open an issue and discuss it with mothacehe <civodul>cuz, it seems that it could always run natively <civodul>as long as the file formats and all are portable <ryanprior>Okay no problem, I ran everything through `guix lint` again just to be sure and I think we're on good footing :) <civodul>janneke: like, you can run an x86_64 grub-install to create the EFI SP of an aarch64 machine <janneke>yes, it looks like the qemu-cross is a hack <civodul>so perhaps it should be #:target #f in the first place <janneke>...but still, guile itself is OK, but it's modules are not <janneke>that was what you first had with the build -f gnu/system/hurd.scm trick <civodul>guile is ok and its modules are not... <civodul>i think we should always be ignoring #:target for modules and extensions ***familia_ is now known as familia
<civodul>could you boil that down to individual bugs? :-) <janneke>that was what i was trying to do with 'guile-target (to set it to #f on gexp->derivation) <civodul>we need to think through it, but i don't think we need any new construct or parameter <raghavgururajan>nckx: Ah yes, I have 8GB RAM. Anyway, it should be relative. Xfe must show lower in your end then. <janneke>i like bug reports, but i'm not really grasping what's going on <janneke>i can try the diff we have now (with the grub etc) on master <janneke>and see if i can get it to build a vm for some other architecture <civodul>janneke: i think we need to look at things one at a time <civodul>a first issue probably is what you wrote: that you can have a native guile with cross-compiled modules/extensions <civodul>a 2nd issue is the whole expression->derivation-in-linux-vm/image machinery <janneke>ah, yes if i could isolate that guile+x-modules thing, that would be nice <civodul>the more i think about it, the more confused i get ;-), and the more i wonder why the heck we're doing all this <janneke>wait, wasn't this qemu hack supposed to be superseded by wip-disk-image? <janneke>that doesn't do legacy grub iirc, but maybe i should work on that <janneke>(the guile+x-modules thing would still be a bug that we need to fix) <civodul>we're still going through the VM thing in this case <janneke>we,ll i'm calling "vm-image" instead of "disk-image" <rndd>i added docker group to my user in config.scm but i still need root to work with docker =( <janneke>i'm guessing that's because we cannot drop legacy grub (or other qemu features) just yet? <apteryx>rndd: and you 'guix system reconfigured' and rebooted? <civodul>janneke: what do you mean by "legacy grub"? <rndd>apteryx: hmmmm, will reboot now *janneke could be naming it wrong 