<raghavgururajan>apteryx: We could remove all the gst inputs from gtk, but that would disable building gtk's gstreamer media-backend. May be we could disable the feature in gst-plugins-bad that removed dependency on qt? <singpolyma>dragestil: those are not in competition. You likely want both of those <dragestil>well, I'm used to git clone, and i heard guix environment is neat because of isolation etc <dragestil>i wonder whether guix environment only checks out the emacs version available in guix package <singpolyma>Ni, guix environment will not check out the source at all <singpolyma>It just makes an environment with the dependencies available <singpolyma>These days we still guix environment emacs as `guix shell -D emacs` <dragestil>interesting. i heard about this new thing called guix shell <dragestil>does guix have a command searching for packages containing a given file, like apt-file or pacman -F? <the_tubular>Could anyone file a bug for me ? My email is all kind of messed up :/ <breathe>Hello, I have some mcron .guile scripts stored in ~/.config/cron/ and I'm wondering way is recommended for invoking mcron on startup. Help appreciated :) <ison>breathe: I think invoking it through Shepherd would be the recommended method <apteryx>raghavgururajan: are there big users of gtk's gstreamer media-backend? <apteryx>in debian it seems they have a separate package for it; libgtk-4-media-gstreamer <apteryx>that's an odd design choice (to make a low level lib that pulls a huge UI-related framework) <apteryx>anyway, I'll try to build gst-plugins-bad without it to see <attila_lendvai>i want to use wrap-program to start my binary like this: ld-linux-x86-64.so.2 my-binary, but wrap-program doesn't seem to support it... any ideas besides doing the wrapping myself? <attila_lendvai>apteryx, it's the official go-ethereum binary. i have already done the downloading and the gpg signature checking as a geth-binary package <attila_lendvai>yeah, it can even be started by: ~/.guix-profile/lib/ld-linux-x86-64.so.2 geth version <dragestil>How do i get python after `guix install python`? it seems to provide python3 but not python. do i need to manually symlink python3 to python? <apteryx>attila_lendvai: depending on the patching you need, perhaps you could hack the binary with patchelf <apteryx>dragestil: install python-wrapper instead <attila_lendvai>apteryx, oh, hrm... that's a good idea. i thought that i'll not touch the binary as per reproducibility, etc... but the package authenticates it from the official download, so i guess i can patchelf it <apteryx>dragestil: no, it won't hurt to have both (python-wrapper is just a symlink to python3) <apteryx>there's 3.9 coming on core-update-frozen <dragestil>i thought guix would be as cutting edge as arch <apteryx>it often is cutting edge; but it depends on the interests of the contributers :-) <apteryx>core-updates has been a bit too long in the making too, which does not help for core packages ATM <dragestil>are the contributors of a package supposed to take responsibility of updating the package as well? <apteryx>and finally someone with commit rights (~50 devs) need to have a last look at it, and commit it if they judge it's fine <apteryx>there's about 700 patches on the tracker currently; lots of them in limbo (waiting on the original sender or on the reviewer); more reviewers/testers/pingers are needed! <dragestil>does anyone know how i can debug python modules? i just guix installed python-debian, but help('modules') output in python shell does not show any debian related modules <dissent>how would i go about encrypting the root partition only and not the boot partition. the double password prompt significantly slows down boot time. <dissent>I don't follow. You'd still need the password but would ideally only need to put it in once. <apteryx>dissent1: I think it's not supported, but perhaps it changed <apteryx>what I'd like is to have some grub solution that caches the passphrase and retries it when the kernel prompts for the 2nd time (or 2nd, 3rd for raid setups) <apteryx>I get 3 grub prompts and 3 kernel prompts for my Btrfs raid1c3 setup. I try to not reboot too often ;-) <apteryx>I know debian has something packaged that makes this possible <dragestil>am I right in saying that `guix pack` cannot be used to pack stuff built "locally" with make? <raghavgururajan>> apteryx: anyway, I'll try to build gst-plugins-bad without it to see <avp_>Hello. Could anyone check the latest Guile-SSH from the 'master' branch with Guix? I made some changes that should make Guile-SSH more stable (e.g. less non-determenistic crashes.) <apteryx>avp_: nice! It's late here, perhaps this weekend! <podiki[m]>for boot pass phrases, you can't add a keyfile like in usual luks dmcrypt setups? <podiki[m]>that's what I've used on arch (with encrypted boot before grub gets loaded) <robin>but haven't evaluated whether that kind of setup is as secure as passphrase-entry or not <podiki[m]>in my case you couldn't get to the boot loader, there is just a prompt to decrypt boot (and if you fail it is a super minimal grub like shell thing); but after that is unlocked it does the root partition via the keyfile <robin>(oh, i missed podiki[m]'s response) <robin>given that involves messing with initramfs behavior, it might overlap a bit with my struggles getting vfio working :) <podiki[m]>vfio is kinda magic and mysterious (like manufacturers not giving accurate info on motherboard support) <podiki[m]>I did use it several years ago with gpu passthrough, was amazing, but finky <robin>it's been totally stable on my system, and pretty usable via looking-glass, but i'm using a fairly high-end motherboard <podiki[m]>in my case I think it was because I was also using the full disk of an installed OS (that ran previously on the hardware directly) and some proprietary graphics driver details <robin>couldn't get it working with kernel arguments, etc., but fiddling with sysfs from initramfs did the trick <podiki[m]>it did work well when it ran, just every once and a while needed I don't know what from me to start up again <podiki[m]>cool stuff though, was fun to figure out and use <dragestil>is there a way to build binaries without hardcoded ld interpreter? <dragestil>say i build emacs in `guix shell --development emacs`, then doing ldd src/emacs gives me /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/ld-linux-x86-64.so.2 => /gnu/store/ksy2b6fwfmz40gjajvspl87ia4vsfzj7-glibc-2.31/lib/ld-linux-x86-64.so.2 (0x00007f9e99ec2000) <apteryx>eh: /gnu/store/8pmlwmlrcf1q0gr2a51xmv3br8k2mby0-polkit-duktape-0.120 ***wielaard is now known as mjw
<florhizome[m]>Can s.o. explain what is core-updates-frozen? Or how the process is going? It seems many packages/fixes I potentially could need are in there (esp meson). Does it make sense to make a guix Shell with one of those branches, and which one? <florhizome[m]>Or does it make more sense to make a local updated meson-for-build? <civodul>florhizome[m]: core-updates-frozen is a branch being stabilized that integrates months worth of "core updates" and assorted important changes <civodul>it's not ready for production use, but you can test it if you want <civodul>the goal is to merge it in 'master' Real Soon Now <vivien>I’m not sure guix shell has been merged into core-updates-frozen yet, so you will only be able to use guix shell from master. <jpoiret>some people here (incl me) are running on a c-u-f system and it's working ok (if you ignore the fact that your timezone is always UTC, the bug is fixed in c-u-f-batched-changes which should be merged into c-u-f at some point) <jpoiret>dissent: the thing is that you can't really put the kernels on the boot partition since they're in the store <jpoiret>sneek: later tell dissent the problem is that the kernels and initramfs are in the store so you'd still need to unlock that partition in the bootloader <florhizome[m]><vivien> "I’m not sure guix shell has been..." <- I think i would invoke guix shell from my normal system and then change my channels or profile in there, wouldn't that work? <florhizome[m]>I haven't worked with environments and Profiles yet tbh, just a lot of concepts there^^ <florhizome[m]><jpoiret> "some people here (incl me) are..." <- which bug 👀 the one that froze? <minikN>civodul: I probably didn't catch your answer, but regarding `search-patches`, if u remember, I tried your suggestion with (apply search-patches my-patches) where my-patches is (define my-patches (list "1" "2" "...")) but I'm getting <minikN>(exception syntax-error (value #f) (value "source expression failed to match any pattern") (value #f) (value search-patches) (value #f)) <jonsger>hm the last piece of the excercise is to get icedove starting with a profile from .icedove and not from .thunderbird... <civodul>minikN: hi! try (apply search-patch my-patches) -> note 'search-patch', singular <civodul>has anyone successfully used the texlive-beamer package? <civodul>it's supposed to depend on "translator", which is not packaged ***isolier1 is now known as isolier
<nckx>dragestil: <is there a way to build binaries without hardcoded ld interpreter> I don't think so, because it's kind of a bootstrapping point: ld.so is what does all the fancy dynamic stuff, not the kernel. <nckx>Every ELF binary I've ever looked at hard-codes it. <dragestil>nckx: ok then how do I port the built binary to another system? <nckx>Change that hard-coded directory to that expected by the distribution, almost certainly /lib, using patchelf. <nckx>jonsger: Slow compared to the equivalent Thunderbird build? That's weird. *dragestil is reading up on patchelf <dragestil>cool, now I'm facing a different error :D thanks nckx <nckx>I'm just guessing, but maybe that error is due to r(un)path, which I think *is* ‘more’ hard-coded on Guix than elsewhere, unlike ld.so. <dragestil>either I have to install a package supplying this library, or find a cleaner way of running bleeding edge dev version emacs on a system that already has a stable version *nckx returns(caffeinated); <nckx>It's called cheating. It was already on the stove when I → ☕d. <nckx>dragestil: I think libjpeg{,-turbo} are drop-in compatible. Not sure though. <nckx>Do you actually have a libjpeg.so.62 on your target distro? <nckx>(Welcome back to life without Guix ☺) <dragestil>I have it after installing it just a moment ago :) <dragestil>what does dropin compatible mean? I suspect they are not mandatory, but the `guix shell --development emacs` supplied all deps <nckx>dragestil: ABI-compatible, sorry. That you can simply replace one libjpeg.so.62 variant with the other one and the programme will just work. <dragestil>ok. well ldd emacs said something like libjpeg.so.62 => not found so it looked non-negotiable <dragestil>now i'm missing another dep that's not supplied by the distro! <dragestil>now the error is `Error: /usr/share/emacs/29.0.50/etc/charsets: No such file or directory`, is this the runpath problem you were guessing nckx ? <nckx>Nope. I don't know off-hand what it is, though. <dragestil>i kinda feel like i know what is the problem, but not how to fix it <nckx>If you explain the problem I might be of use, and if I'm not you still got a good rubber-ducking out of it. <dragestil>so I built emacs in guix with ./configure --prefix=/usr and make install --DESTDIR=/tmp/emacs. I copied /tmp/emacs to the other system also under /tmp/emacs. the paths emacs is complaining about missing are all under /tmp/emacs, for example we have /tmp/emacs/usr/share/emacs/29.0.50/etc/charsets/, just not /usr/share/emacs/29.0.50/etc/charsets/ <nckx>OK, that's all expected so far. <dragestil>and that's the problem, because emacs expects usr/share/emacs/29.0.50/etc/charsets/ under root, not . <nckx>Because you told it to do so with --prefix=/usr. <nckx>configure --prefix=/usr && make install DESTDIR=/tmp/emacs means: I'm going to install you under /usr, so expect your stuff to be there, but for now install your stuff to /tmp/emacs instead of / for $reasons. <nckx>If your $reasons aren't well-defined maybe you didn't mean to use DESTDIR? <nckx>If you want the software to run from /tmp/emacs in ‘production’, use --prefix=/tmp/emacs . <dragestil>uh, I guess i should do --prefix=/tmp/emacs too <dragestil>I just want to put it somewhere temporary for now. Thanks a lot for clearing this up. I did expect it to be a basic question :p <nckx>Just out of curiosity, why did you pass --prefix=/usr? What did you expect it to (not) do? <dragestil> I thought --prefix=/usr would also make things relative path. On the other hand I think I also concerned about the weird directory hierarchy in guix, and just wanted something familiar (/usr). <nckx>The first answer is spot-on. <nckx>--prefix=/usr is certainly the standard, but it's too standard in this case for your own non-standard use case 😉 *nckx AFK, wishes you luck with probably the next error, but maybe a working emacs, which is nice too, I guess. <minikN>civodul: Okay I think I finally got working with `map`. I think it would have worked before but I had my list of patches incorrect. Thanks for your help. <dissent>hey guys, i'm attempting to replicate a profile by download packages from a manifest file. when it gets to building Info manuals I get the follow error The following derivation will be built: <dissent> /gnu/store/ra0zvdi45dbkvvcdswg2h9sch3wr4zms-profile.drv <dissent>building directory of Info manuals... <sneek>Welcome back dissent, you have 1 message! <sneek>dissent, jpoiret says: the problem is that the kernels and initramfs are in the store so you'd still need to unlock that partition in the bootloader <dissent>\builder for `/gnu/store/7x69vwafs3hf9s1mrbx8az6v0di55jbr-info-dir.drv' failed with exit code 1 <dissent>build of /gnu/store/7x69vwafs3hf9s1mrbx8az6v0di55jbr-info-dir.drv failed <dissent>View build log at '/var/log/guix/drvs/7x/69vwafs3hf9s1mrbx8az6v0di55jbr-info-dir.drv.bz2'. <dissent>cannot build derivation `/gnu/store/ra0zvdi45dbkvvcdswg2h9sch3wr4zms-profile.drv': 1 dependencies couldn't be built <dissent>guix package: error: build of `/gnu/store/ra0zvdi45dbkvvcdswg2h9sch3wr4zms-profile.drv' failed <jpoiret>try to use paste.debian.net when posting multi-line logs <dissent>I don't follow wouldn't all partitions have been unlocked during boot. <apteryx>raghavgururajan: eh, gtk still depends on qtbase through v4l-utils@1.20.0 <rekado_>dissent: I had the same problem (info-dir.drv failed to build, but no logs) with a slightly older version of Guix. No more a problem since pulling yesterday. <dissent> yeah it's strange. i can install packages no problem, this error only arises when attempting to install using the manifest file. <apteryx>raghavgururajan: and through zbar also! <dissent>installing gcc seems to be the cause which is strange because I succesfully installed it last night. <dissent>or...at least I got the error when attempting gcc alone <apteryx>raghavgururajan: oh wow, even gst-plugins-good depends on v4l-utils thus qtbase <nckx>Since I know many of you use Android telephones with Guix: I've got one from which I'd need to copy some files to my laptop, but plugging it in over USB doesn't seem to create a device node or anything else useful. How can I mount it? <nckx>Ah, I don't have android-udev-rules installed, that's probably it. <singpolyma>You need an mtp client, if you can find a working one <singpolyma>Or get an app for the phone with an ftp server or similar <singpolyma>If you enable usb debugging adb may have a full command? I know it has a pusd <nckx>singpolyma: Thank you! I had just finished installing jmtpfs and mounting it to /mnt and it just worked (without a ‘device name’, just jmtpfs /mnt; weird.) <nckx>This is (obviously :) not my phone so I'd rather not install things to it, although I have of course enabled ‘developer mode’ which is probably worse. Oh well. <nckx>‘I would like to mount my files please’ ‘OK so first install this weird junk and put your phone in I-would-like-to-use-the-phone mode’. <nckx>Thanks again singpolyma, it was just pure coincidence that I stumpled upon jmtpfs and would have sorely needed your help otherwise :) <singpolyma>They used to support usb mass storage mode, but eventually decided the emulation hacks needed were too hard and everyone just uses the cloud anyway ;P <nckx>They do like to decide what everyone does, don't they? ‘I would like t’--‘no, you don't, f— you’. That's the feeling I now have, after having used the thing for <5min. Great job Googs. <singpolyma>Some prefer the AAPL approach of "I would like t" "I can't hear you over how AWESOME I am!" <roptat>if you want to use the udev rules, you need to add them to your system services <nckx>Not sure what else I'd do with 'em. It didn't work. <roptat>you might also need to add yourself to a group <nckx>Yeah, it was documented in the a-u-r description. I've used the package before, but it doesn't seem to enable USB mass storage mode? <nckx>How do other Guixers connect their presumably Android(-based) telephones with their machine in mass-storage mode? <roptat>ah, maybe not, I use adb all the time <nckx>Surely this can't be hard. <nckx>roptat: Oh, I thought that stood for android debugger 😃 <roptat>yeah, "android debugging bridge", but you can use it for more than just debugging <nckx>OK, but they can't expect ‘users’ to do that, so how do ‘users’ mount the storage? <roptat>you can get a shell on your phone (adb shell), install an app, become root, reboot it, exchange files, ... <roptat>and sometimes debug applications <roptat>they put the phone on their computer and windows installs a driver <nckx>That's genuinely cool but I just want to copy some images, and I feel like I'm missing the obvious way to do that. I had to tap a version number 10 times. It's was all extremely weird. <nckx>So we've regressed to 1990s ‘I've bought a joystick, first to install the driver that came with it’. <roptat>I think in general you would let udisk handle that <nckx>Aha, I will try udisks later. <singpolyma>I find most mtp clients to be unstable but maybe I just have bad luck <roptat>and then you'd use a file manager to navigate the phone <nckx>singpolyma: Does MTP just expose a file system though? It sounds, well, media-oriented. <singpolyma>nckx: you can use it for stuff other than pictures, yeah, it's basically yet another file transfer protocol <singpolyma>I think the gvfs client is based on jmtpfs as well <nckx>I love learning things just not when I have n minutes to e-mail files… :-/ This should have been as simple as ‘mount /dev/phone /mnt && cp /mnt/foo’. It wasn't. If a multi-billion company can't even get that to work, I get angry. <nckx>singpolyma: Good, we needed that, USB mass storage was too universally supported and stable. But really, thanks for the info :) <nckx>GVFS, KDE Connect… So basically I should be using a desktop environment, silly me 😉 <apteryx>uh, even gtk 4 on Debian depends on qtbase through gst-plugins-good through v4l-utils <singpolyma>The claim is that you can't have two computers use usb mass storage in the same storage at once. Of course, you can write a gadget to wrap a virtual file system and sync from there, but they didn't want the bother. They don't expect anyone to use MTP they expect them to use Google photos <nckx>singpolyma: Interesting, and… true, but when/how do two computers ever do that? Do people hook up two laptops to a 'phone? What a fascinating use case. <nckx>It talks to its own internal storage over USB mass storage? <singpolyma>Well, it talks to them in a way that assumes no one else is writing directly to the blocks/filesystem <singpolyma>Usb mass storage expires the raw disk, not the abstract filesystem <nckx>OK, got it. Your ‘Of course, you can write a gadget to wrap a virtual file system and sync from there, but they didn't want the bother’ was my ‘why don't they just’ and I didn't realise. <nckx>So users should install Google Photos, and I'm guessing that's not free software. <nckx>Mmm. I'm starting to see why they just couldn't find the time to get around to writing a USB gadget service too busy so sorry. <singpolyma>I've had blackberry engineers try to tell me a host os and a client sharing a disk with the client over mass storage is impossible. Most devices that support mass storage require a special data partition that the host unmounts when the mass storage client connects. But I feel like the "fake it" is just somehow a thing that doesn't occur to some people as an option? <nckx>I feel like my 12-y-o Nokia manages that just fine tho. <nckx>It prompts me on connection, which is probably the OS remounting things ro, or something, but it works. <singpolyma>Nokias I've seen do the data partition + unmount thing <apteryx>nckx: install adb; enable debug mode on the phone, plug in by USB, then in Emacs: C-x C-f /adb:: <apteryx>oh, you probably also want the android-udev-rules packaged as part of your udev rules <nckx>(Does debug mode lower the security assuming the user isn't going to be the target of malicious evil maids? I'm tempted to leave it on when giving it back, if the only access is over USB, which won't be abused.) <Noisytoot>nckx: My telephone runs GNU/Linux, not Android <apteryx>nckx: if your phone is 12 yo, you shouldn't have much to worry about security (it's already doomed) <nckx>Then you are a better person. <nckx>I'm not worried about my Nokia 2710 at all. <Noisytoot>nckx: I don't think it lowers the security because you need to approve computers on the phone, for which it needs to be unlocked <nckx>There is nothing of security so there is nothing to insecurity. <nckx>Noisytoot: OK, I'll leave it on because I'll be doing this again soon, then I'll turn it off. Thanks. <nckx>apteryx: Interesting by the way. So adb is the way to go? Is it ‘better’ than jmtpfs or equivalent or just different? <apteryx>for me it's more comfortable than having to deal with these more complex solutions which often appears half broken and/or requires chunks of a desktop environment <apteryx>but if you are on GNOME, it could be that you can just browse the files <apteryx>from nautilus if it's still called that <nckx>Yeah, it's probably closest to my workflow. I appreciate all the KDE/gvfs/udisks suggestions but I'd be using software I don't really understand, and that would go wrong eventually. <nckx>apteryx: I think it's called ‘Files’ now but the binary/package is still nautilus. <apteryx>raghavgururajan: I've let go of gtk not depending on qtbase for now; perhaps to be revisited, or perhaps we could create an output for the gstreamer related gtk libs so that at least substitute users would not need to pull qt unless they install such output <apteryx>still feels wrong that GTK depeds on qtbase though; I understand it's probably optionally through gstreamer, but if the big GNU/Linux distributions enable such support, then the optional point is kinda moot. <apteryx>is clone git://root.cern/git/cling.git failing for all? <apteryx>oh, seems they've update the url from git to http <nckx>roptat: Did you also read the ‘new IceCat doesn't render Chinese glyphs’ bug report and think ‘ooh, cool, new IceCat’? ☺ <nckx>I dunno. That's what arnebab suggested. <nckx>I reconfigured my system y'day and had to run it. <apteryx>I've read once on a blog that fontconfig's caching was not required; perhaps there's a way to wholly disable it <nckx>Did it mention the performance impact? <nckx>I'm guessing they're not so masochistic as to maintain caching code (which is never fun) if it didn't make a difference. <apteryx>hmm, it doesn't really say caching is useless, simply that clearing the cache is unnecessary <jab>apteryx: that title is hilarious! <nckx>Wow, building IceCat with (accidentally) disabled swap slowed my system to a crawl. I have --cores=4 with 16 GiB of RAM. Not sure what's up with that. <nckx>…doesn't help that Mu is 3 of those GiB. <apteryx>nckx: you want earlyoom. the OOM killer of Linux sucks. <jorge[m]1234>Throw to key `record-abi-mismatch-error' with args `(abi-check "~a: record ABI mismatch; recompilation needed" (#<record-type <package>>) ())'. <nckx>The build is still running, I wouldn't want it killed. <nckx>I expect the system to be slow without swap, I just didn't expect building IceCat to use 16 gigs of RAM. I see now that it uses clang (has it always?), maybe it's partly to blame. <nckx>jorge[m]1234: You need to ‘make clean-go’ and then run ‘make’ again. That's what ‘recompilation needed’ means. Maybe it could be made more explicit, if there aren't other valid workflows. <nckx>apteryx: I'm ambivalent about earlyoom. Yes, Linux's OOM killer is notorious (to the point of being a laughing stock amongst other kernel communities), but running a daemon that polls multiple times a second(!) just feels like a punchline, not an improvement. <apteryx>saves me hard reboots; polling is cheap ;-) <nckx>I intend to add a zswap service to Guix soon. <nckx>With it, and swap now enabled, memory pressure is down to 0. <dstolfa>nckx: for the longest time (maybe still?) linux's oom killer was killing the process that was the entire reason for my server's existence <dstolfa>"oh look this server's running out of memory, let me kill the process that is the only thing that needs to run on this machine!" <nckx>I don't pretend to know the solution BTW. <nckx>Writing general solutions at such a low level is hard, but having a suite of ‘should never do x’ tests seems like a start. <dstolfa>nckx: i think there's no real solution other than allowing user-configured policies and lifting the functionality, but just killing the process is a really silly thing to do *nckx AFK to emulate trick-or-treating candies-handing-outing a day early in a foreign land. <dstolfa>then again, a lot of linux functionality is really silly *dstolfa wishes that it wasn't... free software would be in a much better state if programming for it wasn't a complete nightmare <singpolyma>My biggest issue right now is that some apps see a lot of free memory and think "mine!" I can build Android apps on a machine with 4gb ram, but now that I have 16 the Android build system still consumes most of it somehow? <slyfox>probably heap size gets configured and build start and uses all you have <dstolfa>singpolyma: yeah... ideally that would be configurable (and maybe is?) <singpolyma>Yeah, there's probably some magic JVM env var or something <jorge[m]1234><nckx> "apteryx: I'm ambivalent about..." <- No entendi, tiene que ver con mi navegador ? <nckx>That message was for apteryx, not you. I answered: jorge[m]1234: You need to ‘make clean-go’ and then run ‘make’ again. <nckx>jorge[m]1234: I missed your previous ‘con Guix pull’ line. I thought you were building from git. ‘Guix pull’ should not print that error. Give me a minute to test ‘guix pull’. <nckx>I feel like I miss context because I don't understand why you mention ‘navigador’ here. <nckx>‘guix pull’ is still running, no error so far. <nckx>It just finished successfully. <nckx>jorge[m]1234: Did you run only ‘guix pull’ with no options? Do you have a ~/.config/guix/channels.scm? <nckx>jorge[m]1234: Yes, please use paste.debian.net. *nckx away for a few minutes. <jorge[m]1234><nckx> "jorge: Yes, please use paste...." <- paste.debian.net/1217290 <nckx>Pulling to the exact same 21fcb commit as you. <nckx>I don't know what could be the cause, sorry. <nckx>jorge[m]1234: Can you run ‘rm -r ~/.cache/gui{x,le}’ and pull again? <nckx>dstolfa: I love, love, love Linux (I choose to run it everywhere, after all) but boy is ‘silly’ the right word. <lilyp>do I just need to scroll up or is it unrelated? <nckx>lilyp: We were talking (I was ranting, the rest was talking) about the OOM killer specifically, but there are several things in Linux that just don't… do the design done very good? <lilyp>oh yeah, Linux' own OOM killer is very conservative <jorge[m]1234><nckx> "jorge: Can you run ‘rm -r ~/...." <- Cual es la orden ? <nckx>It's just interesting how Linux seems to have this internal ‘code quality is king’ image of itself, to the point of intimidating newbies, when outside of that community its reputation is rather the opposite. <nckx>jorge[m]1234: rm -r ~/.cache/gui{x,le} <nckx>rm -rf ~/.cache/gui{x,le} if rm asks silly questions. <jpoiret>I can't run the installation image in QEMU… Looks like qemu's BIOS can't boot the image at all <jpoiret>I built the image using `guix system image --image-type=qcow2 -e "(begin (use-modules (gnu system install)) installation-os)"` <nckx>Which image, which qemu command line? <jpoiret>`qemu-system-x86_64 -enable-kvm -smp 4 -m 4096 -vga virtio -boot d -drive format=qcow2,media=cdrom,readonly=on,file=/gnu/store/ywf8sgfywdm7sfypzhb185ifypmkbzaz-image.qcow2` <jpoiret>true. Although I'm no QEMU expert so I was wondering if this was the procedure to follow <jpoiret>I tried first with the raw disk image to no avail. Also noted that the default installation bootloader is not efi, so no OVMF shenanigans <nckx>Disclaimer: I've never tried booting a Guix qcow2, only ISOs. <jpoiret>oh true, i haven't tried that instead <nckx>I don't really understand the combination of ‘-boot d’ and ‘media=cdrom’ and a qcow2 image. <nckx>What's the reasoning there? <jpoiret>-boot d is telling qemu to boot from cdrom (if it can, if not it'll try everything else apparently) and 'media=cdrom' to use the image as a cdrom <nckx>I get that, but I feel like using an .iso would be the ‘standard’ solution if you just want a virtual CD, or otherwise booting the qcow2 as a hard drive. *jpoiret is building the iso <jpoiret>indeed, booting the qcow2 image as hda does work <jpoiret>i'm not sure what the difference is though but alas <slyfox>qcow2 is probably not an .iso image that cdrom would normally have <jpoiret>i was assuming that these images would all be equivalent except for their format <nckx>Yeah, it's just not a valid CD (CDs aren't just a series of bytes like hard drives and other media). <nckx>They are weird and wonderful. <M6piz7wk[m]>What's the parametrized situation with packages? Is there at least an issue tracking i can contrib to? <M6piz7wk[m]>or like ideally decided on the backend so that i can just contribute options to packages? <lilyp>M6piz7wk[m]: it's just a devel thread currently <nckx>M6piz7wk[m]: There is no back-end. <M6piz7wk[m]>what can i do to speed up the process? it's taking like 3 years now <M6piz7wk[m]>or like what nix is doing with derivations that enable various features <lilyp>IIRC, there is a proof of concept by Ludo, but it's unsure whether it'd be a good idea to add it <nckx><useflags> Uhm. Ideally, something better. <M6piz7wk[m]>singpolyma: i want to avoid adding my own definitions for features <M6piz7wk[m]>bcs maintenance ? i just want to do `services.gitea.nginx.enable = true;` for gitea to work with configured nginx <singpolyma>That's either a second package def or a procedure that returns packages, sounds like <nckx>You obviously have a burning need for this feature. What is it? A(nother) concrete example(s) would probably help move the discussion along. <M6piz7wk[m]>nckx: desire to manage my infrastracture through public repository without much effort <nckx>A lack of compelling examples why this is needed at all seems to be the reason that it hasn't gone anywhere. <M6piz7wk[m]>nckx: so that you can deploy the whole system just from the build? <nckx>I mean, why do you need package parameters? <M6piz7wk[m]>the idea is `nixos-rebuild switch` to deploy the same infra on multiple devices and then do push-based deployment on new merged commit <nckx>Why not just inline (or separate) package variants using, e.g., inheritance? <M6piz7wk[m]>like defining: I want gitea to deploy with onion-service and nginx configured that has set a custom theme <nckx>‘Bcs maintenance’ really means ‘I want someone else to do the maintenance for me’ IMO, which only works as long as someone else happens to be willing to do so. <nckx>A package filled with options is hard to test and to maintain. <M6piz7wk[m]>nckx: i don't mind actively submitting contribs i just dont want to have it as local thing that can't be standardized <lispmacs[work]>hi, are all installed emacs supposed to show up automatically in my Custom Themes list? <nckx>With arguments like that, who can argue. <M6piz7wk[m]>nckx: like you can just cache the build this is configuration on top of that which is easily tested <M6piz7wk[m]>since you can just copy the build result and then test the profiles on top of it <nckx>I can't quite parse that. <M6piz7wk[m]>I need this on GUIX to make it usable for maintainance of huge amount of systems from a public git repo <nckx>I don't see how this is related to parameterised packages though. <M6piz7wk[m]>so that i can just do `services.gitea.enable = true;` for nixos to deploy gitea and give me a framework to configure it in a reproducible way <nckx>This is a service option. *M6piz7wk[m] prepares `sudo rm -r / --no-preserve-root` <M6piz7wk[m]>can you provide me example definition of deploying e.g. gitea with any configuration option/ ***marwan9 is now known as marwan
***eichin_ is now known as eichin
<M6piz7wk[m]>which is all deployed through `nixos-rebuild switch` that is invoked remotely and build on distributed network that deploys the configuration based on domain and hostname <florhizome[m]>I think its basically a matter of time until we have more community channels where more Specialized services and variants could be fetched and deployed. But i don't really think it's the responsibility of maintenance to do that. <M6piz7wk[m]>why not? Maintainer should maintain the package including the configuration assuming that being standardized <nckx>vivien: Thanks! I agree that this should be possible, but can't your extending service simply turn `(("root" ,key1)) into `(("root" ,key1 ,key2))? Why is it limited to appending to the list only? <nckx>vivien: s/to the list/to the top-level list/ <M6piz7wk[m]>give me an eqvivalent of `services.gitea.enable = true;` that builds the thing (and ideally deploys) it and i can work on it <vivien>nckx, do I have access to the top-level list from the definition of a service extension? <nckx>Well, how is your extension extending the list to begin with? <nckx>Doesn't that imply a yes? <florhizome[m]>I mean you basically want to extend gitea and/or nginx and tor ? <M6piz7wk[m]>example: Build and deploy gitea with onion-service configured <vivien>My extension does not know about the base list, it just extends the ssh service to add new keys from a GPG key. The base list is the first keys that are defined in the openssh-configuration, and I don’t think I can get them from the extension. <vivien>The function that collect the base openssh configuration (including the first keys) and the extensions (additional keys) is in gnu/services/ssh.scm <lilyp>shouldn't the merger be compose or append or something like that? <nckx>How can you extend a service without having access to it? <vivien>I don’t have access to the configuration, but I can still extend it. <vivien>lilyp, yes, the merger appends all keys, but in the wrong sense of "append" <vivien>It does not transform `(("root" ,key1) ("root" ,key2)) into `(("root" ,key1 ,key2)) <lilyp>vivien, then you ought to send a patch that repairs said merger, no? <nckx>Without being able to concentrate on how ssh & your service interact, I also feel like this is papering over a (simpler to fix) bug somewhere else. <nckx>(Sorry for the former :) <nckx>Frankly, ("root" ,a ,b) ("bob" ,c) ("root" ,d) just seems like something we should avoid. <vivien>It’s not possible if ("root" ,d) comes from an extension ^^ <nckx>And that's what I genuinely don't understand. <florhizome[m]>Are there extra steps from the gitea side that need be done that nixOS does magically? <lilyp>nckx: vivien is trying to add the ("root" ,d) key by doing something something magic gpg <vivien>nckx, In your operating-system definition, you would have: (service openssh-service-type (openssh-configuration (authorized-keys `(("root" ,a ,b) ("bob" ,c))))), and the `(("root" ,d)) would be computed by another service that would extend the ssh service <florhizome[m]>Of course you can have similar stuff in guix, i don't see the problem^^ but you need those extensions to be defined somewhere. <roptat>I think the only example of something similar is how set-xorg-configuration works <vivien>Certbot does something like that too <nckx>vivien: Only because (compose concatenate) is too simplistic, right? <lilyp>for instance, with users and groups we have a blurb to ensure they're unique <nckx>roptat's suggestion is a very good one: handle-xorg-configuration seems to be the only service that does something ‘custom’ with its own lambda, not a generic one. <nckx>Oh, maybe I missed lilyp's. <vivien>nckx, the openssh-service has a non-trivial extension function, that builds a new openssh configuration from the configuration you passed in your config.scm and the extensions that are computed by other services (see extend-openssh-authorized-keys in gnu/services/ssh.scm). I’ll slightly rewrite this one. <florhizome[m]>Little question, why would a git-reference field be incorrect? <florhizome[m]>I split forge/repoowner/repo/commit/hash into (git-reference (url "Forge/repoowner/repo.git") (commit "hash")) right? <nckx>Guix service composition is extremely flexible (at times it can even feel to powerful), you really shouldn't have to mangle your data structures' integrity just to appease it. <lilyp>florhizome[m]: That's typically correct for most forges, but not e.g. for savannah <nckx>I'm not disputing your bug (at all), just considering the right place to fix it. <lilyp>In this case yes it ought to work, but you might have typo'd <roptat>florhizome[m], what's the error you get? <nckx>That's a more general syntax error. <lilyp>you probably wrote the git-reference in the wrong place? <nckx>Not related to the contents of either string, so not the URL. <lilyp>or made a totally unrelated error elsewhere <nckx>florhizome[m]: I'm guessing you can't share this package in this channel? <lilyp>the syntax would be (uri (git-reference ...)) where uri is a field of origin <lilyp>there is guix-emacs but atm it times out when listing packages <apteryx>Guix itself? or the packages it provides? <roptat>ah interesting, if I use "" as the git-reference URL, it still works, and guix will get the source from swh <nckx>Holy shazam, it does freeze. <roptat>I think guix itself is not reproducible, though most of its packages are <apteryx>it strives to be; some packages still have reproducibility issues; some are reported on the bug tracker <florhizome[m]><nckx> "florhizome: I'm guessing you can..." <- I m logging in via Emacs rn... just forgot my keyphrase again lok <lilyp>Didn't we add a patch to make Guile (and therefore Guix) reproducible? <M6piz7wk[m]>like it's just declaring dependency metadata to ensure reproducibility.. <apteryx>M6piz7wk[m]: about guix iself, that's a good question; we'd have to try but I think a current Guile bug would prevent it from working (building with parallel jobs causes non-reproducibily in the compiled .go objects) <roptat>you have to make sure packages don't record other stuff too, like the time of day, the state of /dev/random or the order of files on your filesystem <nckx>If reproducibility were as simple as ‘record exact dependencies’ Guix (and Nix) would have been reproducible from day 0. <M6piz7wk[m]>roptat: why is that even a concern? are those build not done in a jail? <lilyp>and windows to look at the weather <nckx>M6piz7wk[m]: Building in a jail/container/whatever doesn't fix any of that. Files can still contain the same things in seemingly random order, for example, simply depending on which thread got where first during a particular build. <florhizome[m]>I think its kind of insane to expect that. But having everything quite verbose with good docs and an kinda intuitive language is neat. So people should feel empowered to pursue that. <florhizome[m]>More like, what is needed to reproduce stuff is transparent and achievable. <nckx>Even a fake clock (which is extremely hard to do, if not impossible) won't fix that. <roptat>well, actually I've read a paper that... <nckx>lilyp: Has emacs-guix been like this for a while? <lilyp>I don't know, I only checked this morning <lilyp>It has gathered some bugs on the ML IIRC, but I haven't read those <florhizome[m]>It kinda checks Out for me after a while to... random weird stuff happens <nckx>florhizome[m]: Here, even just a simple ‘p a’ never completes. <roptat>they're doing weird stuff to syscalls and have a fake clock <lilyp>Doing weird stuff to syscalls sounds like exactly the kind of thing you want in a boot jail <roptat>though, the overhead is not negligeable <nckx>OK, but ‘fake clock’ is easy. I'm curious how they fake a clock to be deterministic across instructions & cores & machines. <roptat>iirc, it ticks only when accessed <nckx>Ah, ‘Our container hides these details by al-ways reporting a simple x86-64 uniprocessor’. <roptat>but I don't remember the exact details, so not sure that's exactly what's going on, since it would only work with one thread <nckx>So that'll do it, at the expense of severe performance degradation in addition to the ‘[3.4x slowdown of I/O intensive builds]’. <nckx>Reproducibility: the magic ingredient is overhead. <roptat>I need to remember that for a future paper title :p ***mark__ is now known as mjw
<nckx>Consider that my legally binding permission. <GNUHacker>to manage guix packages with emacs maybe must I install emacs-guix and (setq package-user-dir "~/.guix-profile/share/emacs/site-lisp/")? *nckx now wondering if/how long until a court case will hinge on the legal interpretation of an emojo. <pkal>GNUHacker: I don't think so, Guix packages for emacs should be added to the Emacs loadpath <davidl>I have a package which depends on native-inputs at run-time - are native-inputs at risk of being garbage collect by a regular guix gc -F 10G and similar_ <GNUHacker>Ive installed emacs-guix but I cant do M-x guix <davidl>GNUHacker: define "can't do M-x guix" <davidl>GNUHacker: hmm, have u checked env | grep -i emacs <nckx>davidl: GC doesn't deal with inputs, they are purely a build-time concept. GC considers references, which don't have types. Either a /gnu/store/foo string appears in the output or it doesn't. <nckx>davidl: However, are you sure your package is correct if it refers to native-inputs? <davidl>though Ive made a few minor changes with comments etc in my local gnu/packages/bash.scm <davidl>it builds and installs and works just fine though. <nckx>davidl: Why is everything a native-input? <GNUHacker>Ive env value EMACSLOADPATH=/run/current-system/profile/share/emacs/site-lisp:/run/current-system/profile/share/emacs/27.2/lisp <davidl>because I don't want my guix package -I to show a bunch of propagated inputs. <nckx>No I mean why are they native-inputs and not inputs. <davidl>basically because ./pre-inst-env guix lint bash-bcu told me so I think. <nckx>Native-inputs means they have to be able to run at build time on the build machine, but aren't needed at run time on the target machine (which might have a different architecture when cross-compiling). <nckx>I think something got misunderstood here. What did guix lint say? <lilyp>GNUHacker: that's your problem, it's missing your local .guix-profile <lilyp>source ~/.guix-profile/etc/profile <davidl>nckx: ehm, this time it doesn't say anything (I have a long-winded hypothesis as to why, but Ill leave that out) <davidl>nckx: but so you are saying that if this is an input, it will not be GC'ed? <florhizome[m]>it's not that important; other stuff seems more complicated and i will have to get the git reference thingy sorted out eventually^^ <nckx>Only keep those inputs native- that need to be executed at build time. And, if any of those are also called by your script at run time, your script should call a separate version in ‘inputs’. <lilyp>GNUHacker: It ought to run automatically once you log in again, but it doesn't in the shell in which you run guix install <lilyp>there typically comes a warning reminding you of the fact <nckx>davidl: When building on x86_64 for x86_64 the two will be identical, but not when cross-compiling: the native-input will be x86 and the input (say) aarch64. <roptat>davidl, gc only cares about references, so if the input ends up being used (referenced) in your package, gc won't collect it. If it's not used, then it might be <davidl>nckx: what constitutes "being used (referenced)"? <roptat>as long as the store path ends up in one of the file in the output, it's a reference <nckx>davidl: The string ‘/gnu/store/<hash>-<name>’ occurs literally anywhere in the store directory. <nckx>So ‘A has a reference to this B 1.0 build’ means that ‘grep -r /gnu/store/<hash>-b-1.0 /gnu/store/a’ returns something. <davidl>roptat: so if I have a PATH=/gnu/store/<hash>-<name> in a .sh-file that exists in the output - then it's a reference? <davidl>now I need all the input programs to both run the test-suite at build time, and the same programs at run-time - is it more appropriate to put the in native-inputs or inputs? <nckx>davidl: ‘guix gc --references PACKAGE’ is the official interface to this. Don't actually use grep, although it is really that simple :) <davidl>nckx: sounds like I should take a little look at the source code for that :) <nckx>Sorry, s/PACKAGE/STORE FILE NAME/; force of habit. <davidl>GNUHacker: you should probably have /home/<myuser>/.guix-profile/share/emacs/site-lisp <davidl>GNUHacker: just try adding that and restart emacs. <davidl>you can first check what's in that folder though. <roptat>you probably need to restart it so it picks up the new value <davidl>yes, depending on how you use emacs, you may need to make sure that you restart an emacs daemon <GNUHacker>Ill set (setq package-user-dir "~/.guix-profile/share/emacs/site-lisp/") <davidl>GNUHacker: idk if that works too. <davidl>GNUHacker: personally I don't daemonize emacs, I just start and restart it. If you change your emacs packages you probably need to restart emacs in a new shell (should probably just be needed the first time you install a user emacs-package but anyway). So I would suggest to just do that - restart emacs in a new shell. <katco>hey all. i'm really struggling to understand the usage of gexp. i've defined a service configuration with `define-configuration`. for brevity, let's say it only contains one field `(foo (string "my-default") "my-doc")`. i'm trying to pass the path to `#$(local-file "foo")` in an `operating-system`, but i can't figure out at what stage it gets `ungexp`? the guix CLI suggests it never gets passed to ungexp and says the struct type isn't a string... <davidl>GNUHacker: you could ofcourse inspect the emacs env variables again before starting emacs. <GNUHacker>where is env value EMACSLOADPATH? where I can change? <nckx>florhizome[m]: You're missing two )) after the commit. <nckx>Uh, no, sorry, my fonts are… what the. *nckx using shiny new IceCat :-/ <nckx>But you are missing one, unless things are truly bonked here. (I currently see 1.5 brackets.) <nckx>So move one ) from after the sha256 one line up, after the commit. <podiki[m]>side note: I once had numbers (numbers!!) missing in Icecat. it did not like my fonts I guess <nckx>Running fc-cache -r ‘fixed’ it. <davidl>GNUHacker: in your shell, run: export EMACSLOADPATH=/home/<myuser>/.guix-profile/share/emacs/site-lisp:"$EMACSLOADPATH" ; emacs <lilyp>katco: this service is as it seems not built to receive g-expressions <lilyp>fc-cache -rv is for people who are too lazy to install guix home :P <katco>lilyp: you are likely correct. that's the only thing i could guess, but since i'm still unfamiliar with services, i wasn't sure how to do that. <nckx>Apologies if unintended offence was created, jersey99. <katco>lilyp: i thought that since the issue was with the configuration, i could narrow the scope of the issue to that, but is it the service scaffolding that would be responsible for expanding any gexprs? <davidl>GNUHacker: by the way: you should run: cat ~/.guix-profile/etc/profile to get a better idea how GUIX works with environment variables. <nckx>'T was just a cool badge of serious government scienceness. <nckx>podiki[m]: That is/was surprisingly common, although I don't understand what's happening then. <katco>no, i don't think it's the service. if i do nothing but declare the configuration with a gexp, it complains. <lilyp>Probably some serious engineering decision over at mozilla.org <lilyp>katco what exactly does "declare the configuration with a gexp" mean here? <florhizome[m]>so guix doesn't do fc-cache -rv without guix home? that explains a lot lol <katco>lilyp: in the file where i define all the service/config stuff, i just have `(foo-configuration (foo #~(begin #$(local-file "foo")))` <katco>and my configuration complains "Invalid value for field foo: $<gexp ..." <katco>is the `define-configuration` macro perhaps calling `string?` before it can be expanded? <lilyp>which straightforwardly means that your foo does not take a gexp as configuration <katco>mm, not straightforward to me anyhow. it is not clear to me when in the pipeline gexp are expanded. <nckx>florhizome[m]: Guix doesn't do anything like that (munging ~) at all. <katco>i know that `local-file` will be expanded to the path of the file in the store, being a string, so i thought this should work <lilyp>What is expected in your foo field? <lilyp>katco it only works in the context of gexp->derivation et al. <lilyp>if your stuff takes no gexp, then sad trumpet <katco>in `define-configuration`, i've declared it as a string: `(define-configuration foo-configuration (foo (string "my-default") "my-doc"))` <katco>it made sense to me that the configuration should be defined in terms of the types it requires at runtime, and not the types it can expect at declaration time. i thought guix was supposed to expand gexps before evaluating the instantiation of the config, much like macros? <florhizome[m]>i thought it recomposes fontconfig, forthe user too, bc on the systemlevelit kind of doesn't makesense after installing stuff as user <katco>otherwise, wouldn't all config fields need to be a "gexp" type or whatever, in case someone wants to pass one in? <podiki[m]>nckx: if I remember it happened when I didn't have any (extra) fonts installed and it was probably trying to fallback to something that didn't exist? or maybe was just a caching issue. was odd that letter but not numbers showed <lilyp>katco guix does no such automagic expansion of g-expressions <lilyp>when it does, it'll be documented <lilyp>you might want to use gexp->derivation or similar to get your gexp into a file <katco>ok, let's zoom up the stack: when i run `guix system build os.scm`, is there any gexp expansion going on? <lilyp>the result will be the name of that file <katco>i am trying to understand at what points that will happen, because placing a gexp in my `operating-system` declaration does not work. <lilyp>but few services rely on file-like-objects, e.g. pulseaudio-service-type <lilyp>again, if you want your service to take a gexp, you must make it take a gexp <katco>i've tried looking for examples, but i don't understand services well enough. can you point me to how to do that? <katco>i'm beginning to suspect that you can't use `define-configuration` if you want looser types for your config fields. the examples i've been looking at just use records for their configs. <lilyp>yes, it would seem that define-configuration is rather rigid <lilyp>if you want softer typing you'll need some match-lambdaesque solution <katco>that is beyond my guile skills without an example <lilyp>what are you even trying to solve using gexps? <florhizome[m]>ok so now (after skipping tests -.^) the build fails at "reset-gzip-timestamps", exactly where the original cairo-dock fails too. i can paste the backtrace if s.o. wants to have a look... <GNUHacker>I cant edit ~/.guix-profile/etc/profile, say read-only <GNUHacker>I want add export EMACSLOADPATH=/home/user/.guix-profile/share/emacs/site-lisp:"$EMACSLOADPATH" in this file <lilyp>Is emacs not installed in your guix profile? If so, install it <roptat>"guix install emacs" should solve that <roptat>EXWM is in your system profile I suppose, so it adds emacs in the system, not in your user profile <lilyp>well, exwm is its own beast when it comes to environment fuckery, but what roptat just said <roptat>it's weird, but guix won't set variables unless both user and providers are in the same profile <lilyp>Or simpler: It will only compute native-search-paths for installed packages <nckx>florhizome[m]: Due to read-only files? <lilyp>you only need to reload the file really <florhizome[m]><nckx> "florhizome: Due to read-only..." <- i think? =ice-9/boot-9.scm:1669:16: In procedure raise-exception: <nckx>Run (for-each make-file-writable (find-files ".")) in a phase before 'reset-git-timestamps. <vagrantc>"guix time-machine --disable-authentication --url=/path/to/guix --commit=xyz... -- build X" is in some cases much faster than doing the whole "guix shell --development guix guix git" "./bootstrap && ./configure --localstatedir=/var && make -jN && build X" dance <vagrantc>of course, on the second and third passes, the speed benefits of guix time-machine dwindle <vagrantc>M6piz7wk[m]: not sure what repository you're referring to <apteryx>seems I've locked myself out with a 'herd restart autossh' :-) <M6piz7wk[m]>vagrantc: like user repository which is used to configure guix? <apteryx>wonder if it may have to do with the recent sha1 signed rsa keys deprecation in new openssh <M6piz7wk[m]>e.g. like people are doing with gentoo-config that has the /etc/portage <M6piz7wk[m]>that lisp looks so much more usable compared to hat JSON thing i have to use on nixos <roptat>M6piz7wk[m], yes, it's available upstream <M6piz7wk[m]>wait i can already configure services like this on GUIX? e.g. changing theme in gitea or something? <roptat>there's no gitea service (yet), but we'd love to see your contributions :) <M6piz7wk[m]>if it's comparable to nixos i will get in top contributors :p <M6piz7wk[m]>on NixOS i can do `nix-shell` and it will open `shell.nix` file and creates a temporary environment <roptat>(and there was "guix environment" before too) <podiki[m]>any recommendations for a workflow once you have a package definition that works, but need to tweak to get it fully functional? <podiki[m]>right now i keep doing guix install $(guix build -f package.scm) and then roll-back, make changes, repeat <roptat>well, guix shell would probably be better <roptat>if you have it in, say, mypkg.scm, you can do "guix shell -f mypkg.scm", that will give you a shell with that package <M6piz7wk[m]>aaAAAAAaa why none told me this sooner i was suffering for so long with that on NixOS <Noisytoot>What's the difference between 'guix shell' and 'guix environment'? <nckx>shell is 362% shinier, and addresses some perceived shortcomings of environment (like --ad-hoc now being the default). <nckx>(Side note: it's just ‘Guix’, not ‘GUIX’, although I'm chuffed that you're so enthusiastic 😉) <nckx>Cancel that, I was thinking of Grilo. <M6piz7wk[m]>> Grile was a typo by @kreyren when converting the name from Nixumops to guile scheme <M6piz7wk[m]>When i do mistake i don't~ Origin story of the source code! :P *M6piz7wk[m] also needs to rework his environment management <podiki[m]>this came up recently but now that I have the basics working: would Lutris be fit for guix? <M6piz7wk[m]>i had bad experience with Lutris's devs they were very toxic and untolerative to non-arch distros while refusing to fix compatibility issues in their codebase that i've submitted <M6piz7wk[m]>afaik they have some mental issues that they said were handling at the time? <podiki[m]>well I haven't gotten far enough to see if upstream changes are needed, but in terms of our packaging guidelines <podiki[m]>I think it would fit (I don't think you can directly get their install scripts for games from the program, which I imagine would run afoul of our package guidelines?) <podiki[m]>I take that back, they have added it. so I'm guessing without patching out all of that, would not be for guix? <nckx>I don't know anything about games but vaguely recognise a few names which probably means they are AAA titles and nonfree. <podiki[m]>yeah, used to be you had to use their website, but looks like the finally built in a search from within lutris <nckx>Well, even if the only useful way to use it was to use their Web site, or they linked to it in the programme (which is likely), that would still appyl. <podiki[m]>I mean use their website for install scripts, though you could always use it as a launcher <nckx>‘It's on a separate Web site’ isn't some magical way to get around the FSDG. <podiki[m]>it is/was useful without their install scripts, but now it seems more built-in <podiki[m]>i.e. now you can directly search and install nonfree from within Lutris; even if you use it just as launcher nonfree is right there <nckx>Unless we can somehow patch it to automatically filter by licence, or just drop the non-FSDG title browser entirely, I don't think this is Guixworthy. Sorry! <florhizome[m]>what about waydroid? in general, could ijust bootstrap guix over UBtouch on my fairphone? (if i get to install that ._.) <nckx>If it's about the FSDG, it seems to ship with LineageOS which claims to be ‘free and open source’ (wow! both! that's nice) so it might be OK. <jgart>has anyone run into the above issue with `guix shell`? <jgart>hint: Did you forget `(use-modules (gnu packages))'? <nckx>jgart: Does adding the suggested module import not work? <nckx>florhizome[m]: Yes. (add-before 'reset-gzip-timestamps (lambda _ (for-each make-file-writable (find-files ".")))) <jgart>nckx, When I had tried it gave me a big error. Let me see if I can reproduce it... <jgart>Is importing the modules required now for a manifest? <nckx>florhizome[m]: That'll work too. _ is just what we tend to use in Guix. Don't really know why. <nckx>Oh, because it accepts arguments, never mind. <apteryx>would someone have an idea what that might mean? make[4]: *** [Makefile:6436: tests/publish.log] Error 134 <apteryx>while attempting to run 'make check-system TESTS=basic' on the cufbc branch <apteryx>also 'make check' with -j is known to fail, correct (some tests don't like to be run in parallel) <civodul>apteryx: (status:term-sig 134) = 6 = SIGABRT <nckx>jgart: works for me, even without the import. <jgart>might be a foreign distro thing <nckx>However, I am using an explicit -m ./guix.scm, because without it, it doesn't seem to do anything. <civodul>apteryx: does the log show a message before termination? <nckx>So maybe I have an older or newer guix shell? <civodul>jgart: guix.scm must return a package; manifests go to manifest.scm <civodul>that's why you get the error: guix.scm returns a manifest here <civodul>(a better error message would be nice) <apteryx>commonly failing in parallel; FAIL: tests/pypi.scm, FAIL: tests/store-database.scm, FAIL: tests/opam.scm, FAIL: tests/egg.scm <civodul>apteryx: those must fail due to TCP ports already in use? <nckx>Why didn't I get an error, civodul? <jgart>civodul, works on void linux as expected <nckx>guix shell: warning: no packages specified; creating an empty environment <civodul>nckx: ah, because you didn't authorize the directory? <nckx>That's probably true but very confusing. <nckx>You're right, I thought it was authorised but it wasn't (same name different parent, oops). I think this needs to be much harder to PEBCAK. <civodul>i'll change that if nobody beats me at it <civodul>it makes no sense to create an empty environment in that case <jgart>yup that message is a bit confusing to me too <civodul>in other news, preliminary results on the accuracy of importers: 29% for pypi and 88% for cran (that's the fraction of packages that are the same as those produced by the importer) <civodul>that's on a random sample of 200 packages tho <apteryx>civodul: thanks for the hints! tcp ports seems a likely suspect <jgart>civodul, wdyt of `--rebuild-cache` being automatic/the default for guix shell instead of having to explicitly specify the flag to rebuild the cache? <jgart>I think this is the default for docker or how docker works <jgart>I was discussing this with Ryan Prior the other day <nckx>Doesn't that defeat the purpose? <jgart>If you change the manifest then guix shell should rebuild the cache <jgart>that's how it works for docker <jgart>> Create manifest with 2 packages: python, python-requests. Run guix shell. Decide you want python-lxml instead: exit shell, edit manifest to add python-lxml, re-run guix shell. Type import lxml, it says no module named lxml. <jgart>That's quoting Ryan from our conversation <nckx>That just sounds like a bug? <jgart>That was his experience that he was frustrated with ***LispyLights is now known as Aurora_v_kosmose
<jgart>I tried submitting a bug report for it the other day to bugs-guix@gnu.org but it bounced back <vivien>jgart, there’s no "s", it’s bug-guix@gnu.org <jgart>oh thanks for pointing that out <jgart>now I know why it bounced :) *vagrantc wishes guix@debbugs.gnu.org worked as an alternative method of submission <vagrantc>guix-devel, bug-guix ... why gnu so arbitrary? <vivien>vagrantc, debbugs.gnu.org is currently crumbling under my spamming it with "oops I forgot this" and "sorry I forgot that" <vivien>Anyway, thank you nckx and lilyp for your help, the fix for the openssh server issue is now smaller :) <nckx>vivien: That's the best kind of spam 👍 <nckx>vagrantc: Worst thing is, these are codified rules. <nckx>I don't remember the excuse^Wrationale but someone thought of one. <civodul>jgart: if you change the manifest, 'guix shell' rebuilds the cache <lilyp>something something memory safety <civodul>--rebuild-cache is for the hopefully rare case where that's not enough <civodul>the "no module lxml" is proof that the file was indeed re-read <civodul>(the exact error is due to something in the manifest i suppose) <M6piz7wk[m]>Is there any documentation for Guile Schem used in Guix? *M6piz7wk[m] is trying to define a global variable if env var is set *M6piz7wk[m] * is trying to define a global variable if env var is set else fail <jgart>M6piz7wk[m], there is a short intro to scheme in the cookbook <jgart>civodul, that might have been a hypothetical manifest to explain the problem. Let me test... <vivien>M6piz7wk[m], it’s guile with some syntax to make gexp work <jgart>Sorry if it does work already as intended <podiki[m]>if a program (a python one) tries to find shared libraries by running ldconfig, what's the way we deal with that? do we just disable? <nckx>M6piz7wk[m]: There are some (very) frequently-used Guix helper procedures, syntax, etc. Alas, I don't think most of these are documented, but reading docstrings in e.g. guix/build/utils.scm will get you far. In your case, it sounds like you just need if and getenv, so plain old Guile ☺ *M6piz7wk[m] also messed up the last line <nckx>Uh, that's some very elispy(?)-looking Scheme (that won't work as-is), but roughly, yes. <nckx>Yeah, it gets downright pseudocody at the end, but your aim is true. <M6piz7wk[m]>so like where should i be looking to figure out how to source environment variable? <nckx>(define host-name (getenv "HOSTNAME")) (when (string=? "" host-name) (throw 'error "oopsies")) <nckx>is more like what you'd use, I guess, depending on the context. <nckx>Of course there's no reason to define host-name at all here. <nckx>M6piz7wk[m]: I'll be away a bit, but what do you mean by ‘source [an] environment variable’? <nckx>M6piz7wk[m]: That'll do it. TTYL. <vivien>M6piz7wk[m], (when (or (not host-name) (string=? "" host-name)) ...) <vivien>If the environment variable is unset, getenv returns #f <M6piz7wk[m]>nckx: `HOSTNAME=something guix system reconfigure ...` -> have the something check if it's set or not <M6piz7wk[m]>since i want to have logic that sources code based on HOSTNAME and DOMAIN to manage 500+ systems at once from one public git repo O.o <M6piz7wk[m]>but how do i throw fatal err? Since i need the build to exit if it's not set <vivien>(error "blah") is pretty much how fatal you can get <nckx>M6piz7wk[m]: See examples. throw or error. <nckx>error is just a wrapper around throw that throws a 'misc-error. <nckx>florhizome[m]: The . was just punctuation, a habit I can't shake. <nckx>It's ‘lambda _’, no in-band ‘.’ ☺ <nckx>Oh, (add-before 'reset-gzip-timestamps …) → (add-before 'reset-gzip-timestamps 'make-files-writable …) <nckx>The second symbol is your new phase name, you can choose any meaningful name you like <nckx>(☝ see? It's compulsory.) <nckx>jgart: Have you managed to reproduce Ryan's bug with python3 -c "import lxml"? 
