<teythoon>when i log in, the x server dies saying "server is already active for display 0" <teythoon>slim spins, xorg zombies, herd thinks it is still running <NieDzejkob>teythoon: are you using %desktop-services, or %base-services? <NieDzejkob>hmm, could you paste your system config? I'm successfully using slim right now, so you're probably doing something wrong there :P <bandali>hm, i should probably post to guix-devel about what i did tonight <bandali>so as to give people using git-authenticate somewhat of a heads up that they now need to fetch my key as well <bandali>fishyfriend, you could perhaps then reference my message to the list in your upcoming patch :-) <sirgazil>The information about GitHub limits for API requests is in the manual (by the end of info "(guix)Invoking guix refresh") <sirgazil>However, I created a token, exported the GUIX_GITHUB_TOKEN variable in .bash_profile, started a new terminal, but and I'm still getting the same error. <sirgazil>What scopes do you have selected for your tokens? <raghavgururajan>apteryx Regarding the email I sent you, you can ping me here to discuss or if you need anything. :-) <bandali>raghavgururajan, he seems to have quit for now <bandali>also, email re git-authenticate sent to guix-devel <raghavgururajan>sneek later tell apteryx: Regarding the email I sent you, you can ping me here to discuss or if you need anything. :-) <bandali>raghavgururajan, :-) my second message wasn't directed to you specifically, but rather a PSA-like to everyone who reads here <sirgazil>The GitHub token variable seems to be found, but now I get "Error downloading release information through the GitHub API when using a GitHub token". So I may be missing some scope... <raghavgururajan>bandali The order of patches are numbered. Also, more on its way. :-) <bandali>raghavgururajan, nice work, and i very much am! but i sadly barely have any time on my hands right, and i seem to recall that people had responded to your posts to guix-devel about linphone <bandali>if there's no further feedback and/or you don't get it merged in a week or two, i'll set aside some time to review and give feedback (if any needed) and hopefully merge afterwards :-) <raghavgururajan>bandali Oh, guix-devel mail thread is different. It was qt-version of linphone. <NieDzejkob>lfam: make sure you close patches when you push them ;) <jsoo>Is there a limit on consecutive patches sent? <NieDzejkob>jsoo: I don't think so, I've seen some people send 200-patch patchstacks IIRC <jsoo>hmm. i sent a few today and haven't seen an ack yet. usually it's pretty fast to respond <bandali>jsoo, i think there've been some slowness in gnu lists's mail queues today <bandali>raghavgururajan, ah :-) alrighty, i'll keep that in mind *raghavgururajan finds only four patches on the bug-thread. 6 more is missing. <bandali>the gnu mail queues have been a bit slow today it seems <bandali>atw, congested gnu lists mail queue today :-) <atw>mm yeah. I'm particularly excited about this because if we can get those tests fixed we can have a synapse (matrix server) package. I'll check back tomorrow and see if I can get some help with the failing tests. <jsoo>Does anyone know how to get proof general working as an emacs package instead of a standalone executable? <jsoo>It provides site-start.d containing pg-init.el. <alextee[m]>running guile-tools c2doc tells me: guild: unknown script "c2doc" <Gamma02>At booting Guix its says 'Missing free firmware(non-Free firmware loading is disabled)' which means is it possible to enable it ? <bandali>nope, the linux-libre kernel shipped with GNU Guix does not include any binary blobs and does not have any mechanisms for loading them <Blackbeard>With all the people inside I could imagine internet being specifically slow <bandali>i've heard from a few people about increased latency as of late <Blackbeard>Everyone is using steam or tiktok and all that crap 😑 <Blackbeard>It should be frown upon just like buying toilet paper <alextee[m]>Blackbeard: ive been having a bad internet experience lately too <bandali>it'd be interesting to look at global internet traffic/bandwidth graphs <apteryx>jsoo: should be as simple as running the emacs-build-system on that lone pg-init.el file (if that's where all its code is?) <sneek>Welcome back apteryx, you have 1 message! <sneek>apteryx, raghavgururajan says: Regarding the email I sent you, you can ping me here to discuss or if you need anything. :-) <apteryx>I believe there is a proper channel for nonguix <Gamma02>Is there a difference b/w 'sudo guix pull' and 'guix pull' ? <apteryx>rekado_: is it normal that the nfs-service seems really heavy on IO to start? I'm only sharing a /pub directory with nothing in it so far. It halts the boot, and I can hear the rotative disks grind for a while. <apteryx>Gamma02: yes, sudo guix pull you are running as root in your user profile. Not a good idea. <apteryx>it'll create files owned by root in your home and you'll have permission issues later on. <apteryx>If you want to have a dedicated root profile, you must change to the root user before using guix pull, using something like 'sudo -i'. <apteryx>interesting. Perhaps I'm mistaken then, although I seem to recall there was an issue with doing 'sudo guix pull'. <brendyn>right, so sudo guix uses your users guix to access the roots profile <guix-vits>fishyfriend: but they may describe features that not yet in the installation images (old ~1 year now) <brendyn>Gamma02, what topic do you mean when you say nonguix? <sulr70>You can consider to buy a usb wifi adapter with ath9k chip <Blackbeard>Mine can even block my neighbours WiFi when they put music too loud for hours. <guix-vits>brendyn: probaly by buying 20 dongles, and running hot-spot with `cat /dev/zero >> /dev/null` (joke) <brendyn>guix-vits, that doesnt make any sense. <Blackbeard>brendyn: I am having trouble to send you a PM, can you please send me one ***brendyn is now known as brendyyn
<brendyyn>Blackbeard, what matrix client do you use? <Gamma02>I occurred some problem, running sudo guix pull seems to work but guix pull freezes. Why does this happens ? <brendyyn>i hope your profile didnt end up getting owned by root <rekado_>apteryx: I don’t see why the nfs-service would cause high IO load. Can you perphaps instrument it? ***rekado_ is now known as rekado
<brendyyn>does linux automatically load the free firmware onto wifi cards? <bricewge><raghavgururajan "Hello Guix!"> Hello raghavgururajan <brendyyn>i tohughtit was something that was embeded in the card, and you needed some leet hacking skills to change it over <raghavgururajan>I have a doubt. Let's assume I have two source balls, A (v2) and B (v1), for same software. Both has a C file (foobar.c) at /src/base/foobar.c. A's file has syntactical errors. If I want replace the file A/src/base/foobar.c, with, B/src/base/foobar.c; inside the package definition of A; how do I do it? <Gamma02>brendyyn: Okay, should I use chown ? <brendyyn>Gamma02, im not actually sure what the issue is. can you check it with ls -lha .guix-profile? <Gamma02>brendyyn: Yep the user and group has changed to root. <Gamma02>Can't change, its read only file system when ran with sudo. <guix-vits>raghavgururajan: idk, but what about make a "A B diff", and use the patch-facility of guix-build? <Gamma02>sudo chown -R gDust:users .guix-profile/ <brendyyn>I'm not sure what's happend, can you send in a bug report? <Gamma02>Do you want me to send the command output ! <raghavgururajan>guix-vits I was thinking about it. Not sure how to do it. Let me go through code base. <Gamma02>I ran the command sudo guix pull, supposed to be guix pull. Thats it now every files under .guix_profile is root:root can't change the ownership even with sudo. <rekado>Gamma02, guix-vits, brendyyn Do not attempt to change the ownership of files in .guix-profile <rekado>a) you can’t, b) they are immutable store items, c) store items are root-owned, d) on Guix System the store is remounted as read-only <rekado>don’t try to change what isn’t broken <guix-vits>rekado, brendyyn, Gamma02: i'm sorry for suggesting -R. <rekado>the problem is not with -R but with potentially dangerous advice of using chown on store items at all. <rekado>I strongly urge you to investigate problems before changing unrelated things. <guix-vits>compress rekado --> "you only need to change the symlink (~/.guix-profile) ownership if you'd ran guix pull as root, Gamma02." <leoprikler>raghav-gururajan: Put that into the patches folder and then inside the package definition do (search-patches "my-fancy-diff") <leoprikler>you need an annotated diff, i.e. one that tells you which file to patch <brendyyn>hmm. wrap-program has a phase do detect if a propram already is a wrapper, but im still getting ..foo-real-real <leoprikler>You're probably doing wrap-program .foo-real as well. <leoprikler>That happens if you naively list all the binaries in e.g. /bin <leoprikler>Perhaps we should find-files in a way, that ignores hidden files? <brendyyn>im using im justusing the python-build-system 'wrap phase <leoprikler>But outside of that, if you need to wrap-program just a specific file, you can usually hardcode that into your phase. <brendyyn>yes i was looking for a more general and composable way to do wrapping <brendyyn>for example python programs that use meson-build-system often just copy-paste what is essentially the python wrap phase <brendyyn>some programs use @@ to call in the phase, which seems nicer <brendyyn>I think it would be nice if these wrapping procedures were modular. you could just say wrap-pythonpath <leoprikler>If you really need a wrapper from another build-system, (assoc-ref that-build-system:%standard-phases 'phase) <Gamma02>Is there an option to run guix in debug mode ? <leoprikler>either way, yeah, I personally think that's pretty bad *raghavgururajan tried patching technique inside build successfully. :-) <leoprikler>@@ accesses hidden functionality and IIRC won't be available with Guile 3, because Guix uses declarative modules. <brendyyn>so we should have removed it all from guix? has that been don on core-updates? <leoprikler>IIRC builds are still stuck on Guile 2.2 so you're not noticing any of that <brendyyn>its hard figuring out what magic is required to import the right stuff into the build. there is both #:modules and #:imported modules <raghavgururajan>Folks! How do I pass an argument in cmake-build-system to complie with "-fPIC" ??? <brendyyn>leoprikler, do you think it would be good to develop some wrapping language? <leoprikler>IIRC you can do cmake -DMY_DEFINE and it should work <leoprikler>brendyyn: It's not that hard, you just have to add the system you're referencing to modules and assoc-ref it inside. <brendyyn>yeah i just found its about the same amount of lines as copy-pasting the wrapping procedure <leoprikler>Admittedly, the modules syntax itself is a bit clunky and it could help if the ones needed by the build system were added automatically <brendyyn>raghavgururajan, all i did was quickly scan the repo when you asked. with over 10,000 packages you can almost always find an example of what you want to do <leoprikler>It could also help if one had (build-system (list ...)) <leoprikler>Perhaps one could try to code that for the next c-u. <leoprikler>Once you do mix various wrapping standard phases, you'll inevitably have .....foo-real-real-real... <leoprikler>Because wrappers don't ignore hidden files and perhaps they should. <brendyyn>but wrap-program has the already-wrapped? bit <brendyyn>i think it or the wrap phase of the build system should check if it is a .*-real file and not wrap it <leoprikler>yep, you could try matching the whole name, that'd work <leoprikler>my claim is that we can ignore any file with a leading ".", as only guix creates those in the first place, but it's little different from your method. <brendyyn>yeah may as well just do that and not complicate things <kondor[m]>What should I install to run java programs on Guix? Note that I'm not the biggest Java expert ever :D <kondor[m]>I mean, I know there are different implementations of JRE and SDK and so on, just wondering what's the thing to install on guix <rekado>kondor[m]: install either the openjdk package or icedtea. <rekado>you will not need the “jdk” output if you just want to run programs <rekado>the jdk output is for … the JDK (including javac et al) <kondor[m]>rekado: and what if i want to make a java package definition? do i take openjdk as an input? <kondor[m]>(that's what i'd normally do, just not sure if the package itself is huge and there is some -minimal variant) <kondor[m]>aaah, i see, openjdk is the jre more, or less and icedtea contains the build tools, too <kondor[m]>but, then, i guess, in guix i can't just download a jar package of the java program I intend to export to guix. I should go for the source directly, use :jdk for the build-time input <kondor[m]>and propagate openjdk without :jdk as a dependency *raghavgururajan finally built mediastreamer successfully. \o/ <sarg>I'm struggling to make autocompletion and go-to-symbol work in "The Perfect Setup". So I open some guix module, do M-x run-guile and then with point at `package` try to geiser-edit-symbol-at-point. It doesn't work. I suppose the REPL doesn't know anything about `package` definition despite having guix in `geiser-guile-load-path`. Please shed some light on how to fix that? <kondor[m]>I guess we do not have (yet) a maven-build-system ? <guix-vits>sarg: try log off and log-in your user's session. <guix-vits>is that ok if i just copy %base-services to my sys. config and rename it as &my-base-services? It's easier than use (modify-services, as i can inject my customizations directly. <kmicu>If you are not interested in future changes to %base-services automatically apply to your system then you can do it safely. <brendyyn>guix-vits, you can. you will need to add a few module imports though <guix-vits>kmicu: i'll try to make some script to compare my module (i'll put this in module) and %base-services... thanks. <guix-vits>brendyyn: thanks. i'm lucky: as `guix` shown me the hints (with exact modules i'm need to include). <3 <rekado>kondor[m]: you would use the ant-build-system in most cases <kondor[m]>rekado: i was about to try that after I looked into build/ant-build-system <kondor[m]>it's just that the build instructions for the program in question use maven <sarg>Okay, I've solved half of my issue with "The Perfect Setup" by `guix-devel-mode` and `guix-devel-use-module`. Now I'm facing some disrepancy between what location autodoc shows (it's correct) and where `geiser-edit-symbol-at-point` jumps (first occurence of the symbol's name in a file). *jsoo figured out how to make proof-general work <guix-vits>sarg: are you've Guix as a package manager on top of the other OS? <sarg>guix-vits: yes, that's right <rekado>kondor[m]: we don’t have a generic maven build system yet, but the ant-build-system can generate a build.xml even if it doesn’t exist. <rekado>if the Java package in question is simple enough the ant-build-system might work. <teythoon>i more or less copied your services configuration, the error was the same <teythoon>however, rebooting fixed it for some reason :/ <kondor[m]>rekado: yeah, that's what i tought after I looked into the ant build system definition. i've noticed a file called *build.xml* gets generated, just wasn't sure if that's an configure.ac level file, or a Makefile level file <mbakke>I think roptat has a mostly-working build system though, with luck it's merged within a few days :) <efraim>internet connectivity is so bad here right now my house has been offline for hours and even my cell connection is spotty <efraim>i'm down to building packages from source to minimize the amount of time spent trying to download substitutes <brendyyn>last night before i fell asleep i was ruminating about building some system for compressing substitutes based on previous substitutes. i had lots of ideas. it would be tricky to keep it simple and worthwhile <brendyyn>like if you wanted to download some new chromium derivation, it could be downloaded as a diff based on the last build version, using some binary diff tools and deduplication <brendyyn>i will have a look. i know the gaming industry does it alot since they have many GB/s to update <mbakke>brendyyn: civodul mentioned recently that Nix used binary deltas in the early days, but that the approach had some complications <brendyyn>i guess its an enticing idea, like P2P, but in the end its hard to make something superior to traditional downloads <efraim>I forget if he said it was slower or had a low hit rate <brendyyn>I was thinking about not making diffs of just one previous build. but of scanning the store for all builds of a certain kind and making some kind of diff that would work for all of them, or give up if not compatible. <brendyyn>if the build server was using btrfs and deduplicated the store, it would be quick to check if a file is identical when scanning <brendyyn>i recall there was some microsoft article that made some tool that worked much better than bdiff <brendyyn>hmm 30 minutes and I'm not getting a debbugs response after email guix-patches@gnu.org, and its not in the archive <brendyyn>oh and a patch i sent a few hours ago is dead silent too. <wxie>mbakke: GUIX 1.0.1 has problem with coreboot as expected. <brendyyn>and responses to bug reports appears to be down. seems debbugs is dead atm? <wxie>mbakke: Load config from (usb0) => error: file '/boot/grub/i386-coreboot/gfxterm.mod' not found. <jsoo>brendyyn: I sent a few today with no acknowledgement. I think it’s either down or very slow <wxie>mbakke: error: file '/boot/grub/i386-coreboot/vbe.mod' not found. <wxie>mbakke: error: file '/boot/grub/i386-coreboot/vga.mod' not found. <mbakke>wxie: odd that it tries loading files from 'i386-coreboot', it should be 'i386-pc'. <mbakke>wxie: do you have Guix installed on another computer (not necessarily Guix System)? we can try to make a new ISO with a workaround, though I'm not yet sure what that would entail. <roptat>mbakke, I do have a working maven-build-system, but it needs to go through core-updates, which is currently frozen <NieDzejkob>roptat: Neat, have you posted your patches somewhere? <NieDzejkob>(a quick search for maven-build-system on the guix-patches archive didn't yield anything fruitful :/) <wxie>mbakke: No, I don't have another guix. <wxie>mbakke: Ignore the error would not work => it loads the default system. <NieDzejkob>how do we handle it when libfoo.a depends on libbar.a, which depends on libbaz.a, all in separate packages, and the build of libfoo needs to access libbaz? <NieDzejkob>is propagating libbaz in libbar sensible here, or will it have unwanted side effects? <ngz>NieDzejkob: propagated inputs are (also) required at run-time. I don't think you need ".a" files at run-time. <Veera>App create pixel art and manipulate digital photos; where to place? photo.scm; gimp, inkscape are kept separate <mbakke>roptat: why does it have to go through core-updates? <roptat>because it changes the whole ant build system too, and I need to rebuild packages that are very deep in the dependency graph <mbakke>NieDzejkob: propagation is the usual solution. If the packages use pkg-config or libtool, you may get by with inserting -L /gnu/store/...-libbar/lib references in the .pc or .la files though. <NieDzejkob>mbakke: yeah, I think there's some libtool involved. I'll try to get by without propagation then <mbakke>roptat: there are only ~424 packages that depend on ant-build-system, most of them pretty small, it could be done on 'master' IMO. <mbakke>NieDzejkob: you may find some inspiration in 'libarchive' or 'openldap'. <guix-vits>Veera: Hi. Maybe to graphics.scm? blender is there. <NieDzejkob>roptat: and even if not on master, staging would definitely work <mbakke>roptat: on a related note, the GTK+ and LLVM size fixes you made on core-updates could have gone through staging too instead of lingering on core-updates forever. No use now, though. :) <guix-vits>Veera: though graphics.scm maybe for 3D-stuff? <swedneck>hi all, is there a live ISO one can use for testing a full guix install? <Veera>guix-vits: photo.scm ; darktable is there <Veera>guix-vits: image manipulation and creation is graphics <mbakke>wxie: can you report the issue on guix-devel@gnu.org? I hope someone more familiar with coreboot can chime in. <guix-vits>Veera: idk:) but rawtherapee in photo.scm too. Is this app primarily for photos, or maybe it need to go to game-development.scm? <swedneck>mbakke: that page only has an installer, QEMU image, binary, and source <Veera>I see in image.scm only viewers/ <swedneck>what i'm looking for is an ISO i can boot directly into a desktop environment <Veera>App primarily for image creation and editing <NieDzejkob>Veera: don't think about it too much, pick something that makes sense and move on <mbakke>swedneck: I see. If you have Guix installed, you can create a bootable ISO of any system configuration file with 'guix system disk-image --file-system-type=iso9660 my-config.scm'. <NieDzejkob>if someone objects, they automatically volunteer to tell you where to put it and why <swedneck>mbakke: so i guess the easiest way would be installing in a VM, and then using that to make a live ISO? <NieDzejkob>swedneck: you could install Guix-the-package-manager on your current distro <swedneck>yeah but guix-the-package-manager is different from a full distro, isn't it? <swedneck>with it installed in a VM i have everything i'd want for testing on a real pc, but if i installed the package manager i'd have to configure all that manually first <Veera>guix-vits: interactive just like gimp and inkscape <mbakke>swedneck: there is not really anything to configure, they work exactly the same <swedneck>mbakke: but in the vm i already have things configured so it shows a login screen and lets me start a DE, how would i do that with only the package manager? <mbakke>swedneck: you'll need to create a config.scm in both cases <mbakke>even on Guix System, you would not be testing configurations on your live system, you would use 'guix system vm' or similar, which works the same on any distro <swedneck>i just want to try a full guix distro install on my laptop since i get absolutely awful performance in a VM <mbakke>swedneck: if you want to test your config.scm on actual hardware, you can create a disk image from it as mentioned earlier and copy to a USB drive, though you won't get great performance by booting that either. <mbakke>swedneck: easiest way is to run the installer and re-use your existing config.scm <Veera>guix-vits: in image.scm i only see image libraries <Veera>nckx: If I put in image.scm and make a patch do I have also have to update the used modules in top or it will be done upstream <rhou[m]>I tried to manually install guix-system but guix system init fails with this message: error grub-install modinfo.sg doesn't exist please specify --target or --directory <rhou[m]>and specified the grub-efi-bootloader <mbakke>rhou: did you label the EFI partition as an 'EFI System Partition'? <mbakke>i.e. 'set <partnum> esp on' in parted <guix-vits>Veera: you send a patch to module, so module should work, so you need to include the #:use-module thing (or builds and installs of the package will not work). <guix-vits>Veera: funny enough: there is separate image-viewers.scm <guix-vits>Veera: do you want to ran the tests on the package mentioned? <guix-vits>Veera: ./pre-inst-env guix lint PACKAGE (in guix environment) <nckx>Veera: to generalise guix-vits's answer, each patch and commit must result in a working package + Guix. <Veera>guix-vits: ran ./pre-inst-env guix build; what's P <rhou[m]><mbakke "rhou: did you label the EFI part"> yes I did <mbakke>oh my, stackoverflow is down, good thing it's a weekend :P <janneke>mbakke: now with core-updates frozen, is it still OK to push patches from the new "wip-hurd" -- CI seems fine with it and /seems/ to agree that no rebuild is triggered? <mbakke>rhou: are you sure you've booted in UEFI mode? Does /sys/firmware/efi exist? <g_bor[m]>have anyone tried to get debbugs control message trough today? <mbakke>janneke: I skimmed through the commits and as long as the low-level changes are guarded with ,@(if (hurd-target?) ...) as they seem to be it should be fine <g_bor[m]>I tried to close a bug twice already, but somehow it's not working for me. <mbakke>janneke: if some of these changes make sense to "inline", please leave a TODO like "remove the if clause on the next rebuild cycle". <janneke>mbakke: ah right -- i don't think so, but i'll have a close look! <brendyyn>civodul, emails appear to not be going through to debbugs for the last few hours. <mbakke>janneke: Berlin has not started the full rebuild yet, so it's not a crisis if rebuilds are caused, I'm probably the only one who will notice! :P <mbakke>brendyyn: we don't have any control over the GNU infrastructure, can you ask on #savannah what's going on? <rhou[m]>> rhou: are you sure you've booted in UEFI mode? Does /sys/firmware/efi exist? <rhou[m]>I just booted the guix installation image with qemu, how do I enforce uefi boot? *janneke wistles innocently <g_bor[m]>rhou: you have to use ovmf for the qemu image bios. <Veera>rhou: start qemu with uefi bios <Veera>rhou: see OVMF.fd or something similar <Veera>rhou: run qemu-system-x86_64 -bios OVMF.fd ... <civodul>so it looks like there are confirmations of graft segfaults <mbakke>rhou: 'qemu-system-x86_64 -bios $(guix build ovmf)/share/firmware/ovmf_x64.bin' <your-arguments> <mbakke>civodul: time for a new rr session I suppose? :/ <civodul>rr was nice, but those debugging sessions are exhausting <g_bor[m]>I do not think that we can do any better with isolating this. <g_bor[m]>civodul: do you have any idea where these segfaults come from? <g_bor[m]>mbakke: I was thinking about the ovmf stuff in guix for a while, it would be nice to have a better support. <g_bor[m]>What bothered me is how to solve the writeable part of ovmf. <g_bor[m]>Maybe a virtual-machine service could do that... <janneke>g_bor[m]: did you find any time to work on something postfix? <civodul>g_bor[m]: regarding the segfault, i would need a detailed bug report with a way to reproduce it <g_bor[m]>My next step will be to investigate how to extend support for setuid programs. <civodul>i suppose it's another obscure VM bug <mbakke>g_bor: virt-manager supports OVMF, I think? <g_bor[m]>I believe I will create a wip-branch for that. <mbakke>g_bor: what do you mean by extend support for setuid programs? <g_bor[m]>For postfix we need fine-grained setgit and setuid support, and I believe it would be nice to have this mechanism available elsewhere. <mbakke>g_bor: you mean apart from (setuid-programs ...) in the OS configuration? <g_bor[m]>I could come up with seomthing adhoc, but I was thinking about something lie a setuid-program record-type with fields: uid, gid and gexp, and making setuid-programs able to accept these as well. <g_bor[m]>currently setuid programs only setuid and setgid everything to root. <mbakke>right, I suppose a setuid-program-service-type that defaults to root, the (setuid-programs ...) field could then be implemented in terms of that, and other services could extend it *mbakke goes to watch snow melt in the glorious sun for a bit <g_bor[m]>This turned out to be very indeterministic. <g_bor[m]>If I do a system reconfigure again and it still triggers, then there is a good chance that it does more than once. <ericst>Hello, I am trying to package with guix. And I have created a dedicated channel for my experiments so far... Is there a way to force guix to use my working directory for this instead of having to commit every change ? Should I use GUIX_PACKAGE_PATH ? <Veera>mbakke: virt-manager in Debian supports OVMF <g_bor[m]>Can I do something that would help debug this when I run the command again? <mbakke>Veera: but not Guix's virt-manager? <ngz>ericst: a dedicated channel can be a directory, not necessarily a repository. I.e., you don't need to commit everything, do you? <ericst>ngz, really ? I specified file:/// in url and when I do a guix pull, it complains if it is not a git repo... <ngz>ericst: Well, I /think/ it is possible. Otherwise, you can rely on GUIX_PACKAGE_PATH, as you mentioned (that's what I use). <civodul>g_bor[m]: having the name of the derivation that led to a crash once could help <ericst>ok I will see if I can force it somehow, otherwise, I will go with GUIX_PACKAGE_PATH, thanks <raghav-gururajan>There is a variable "antlr3-3.4" in java,scm, but the variable is not public. How can I use the antlr3-3.4 version? I am able to use antlr3 (3.5) and antlr3-3.1. But not antlr3-3.4. <cbaines>civodul, I took note of what failed when I ran guix package -u on my laptop and sent it to bug-guix <cbaines>I think the mailing list/debbugs is a little slow though, as that was 3 hours ago <civodul>yeah there are problems with debbugs apparently <civodul>i saw a message of lfam to help-debbugs <janneke>finally: current core-updates supports building "hello" natively on Debian/Hurd: <janneke>/gnu/store/dpz54d216rdvrgnz49hfly104242j2al-hello-2.10 <janneke>and -- as if it's a conspiracy -- i think that since recently we also have guix system --target; would that give us a magic combo? <janneke>thank you, and thanks a lot efraim, mbakke, civudol getting this done! <guix-vits>janneke: did you send the message to hurd-devs? <janneke>guix-vits: i'm not even on hurd-devs *janneke looks up hurd-devs *janneke pushes first DRAFT commits towards a `bare-hurd' system to wip-hurd <pkill9_>is berlin substitute server slow or does my internet suck <brendyyn>pkill9_, its on my list to experiment with such things. very difficult to make work <jonsger>distributed user-runned CDN would be enough I guess :) <rhou[m]><mbakke "rhou: 'qemu-system-x86_64 -bios "> 👍️ thanks! <civodul>rekado: thanks for fixing the videos! <civodul>so we still have to fix those GNOME issues <guix-vits>had some strange issue with ERC just now: C-l on #guix "broke" buffer rendering. now everything is good. <Veera>CVE db downloaded by guix lint; is it per pkg <Veera>no. I have unreliable inet; so for prev years, I want to download it once only. <civodul>janneke: there's a couple of rather critical GNOME bugs <civodul>that would be nice to fix for the release <guix-vits>Veera: idk, but think that the lists should be updated from time to time. I'm not remember it to be re-downloaded for me. <civodul>one of the bad things with rare releases is that mistakes are less easily forgiven :-) <jonsger>civodul: you wanna fix them on 3.32 or first merge the wip 3.34 branch? <Veera>guix-vits: It got it downloaded once. But it got deleted, so it is downloading again. <civodul>jonsger: i doubt we can merge 3.34 and have something that works overnight :-) <Veera>guix-vits: Is there a way other than lint to download it. <civodul>what's the status of the 3.34 branch, actually? <jonsger>don't know. Can't build because of missing subsittues <guix-vits>Veera: i just submitted "almost-my" first package yesterday, to be honest. <Veera>guix-vits: are you also a outreachy participant <jonsger>civodul: so we don't merge core-updates before release? <Veera>guix-vits: I thought you were guix member <guix-vits>Veera: i'm an "gamer-on-withdrawal", spending hours on the computer. <civodul>jonsger: i think core-updates will take another couple of weeks to stabilize <civodul>so it seems that the GNOME Terminal font issue disappeared? <guix-vits>Veera: i was planned a dual-boot with Fedora, so called user guix-vits to not mess my $HOME. <Veera>want to submit patch for app lib-calc and calc-gtk. should I make a patchset? <NieDzejkob>huh, the hash of the new version of ntl starts with 1lisp <Veera>nikita`: i managed to compile xplanet; with some patches from pkgsrc and other... <ericst>My package builds but then the validate-runpath fails because some of the libraries are dependant on other generated libraries <ericst>it then complains that those are not in the run-path <ericst>how can I make guix understand that the package itself should be considered for the run-path ? <lfam>ericst: What build system is it? <NieDzejkob>ericst: If you temporarily (delete 'validate-runpath), do the libraries load correctly at runtime? <nckx>Veera: <should I make a patchset?> I can't find projects called lib-calc or calc-gtk on DDG. Could you provide or link to details? <ericst>well, that I would have to check... It is actually a library (OmniORB) dependency for something else that I want to package (OpenModelica) <lfam>ericst: In general, you should try setting the rpath (runpath) <efraim>ericst: you might need to grep the source for similar instances, try: git grep rpath | grep \"/lib <lfam>I would specifically look for this: "LDFLAGS=-Wl,-rpath=" <lfam>You'll find a lot of examples <Veera>nckx: they were just example name; have not submitted yet; libqalculate and qalculate-gtk <lfam>ericst: Try copying one of the examples you find <nckx>Veera: If you have the time and the burning desire, why *not* submit patches? Both LGTM. <Veera>nckx: I am going to submit; wanted to know proper way; both going to be in maths.scm; one below the other; so a patchset will make sense; thought so. <nckx>If by ‘patch set’ you mean two patches: yep. Always 1 package per patch. <NieDzejkob>argh, debbugs seems to still not be ingesting mails <Veera>nckx: two commits; git format-patch --cover-letter -n --thread-shallow [PATCH 0/2] <guix-vits>NieDzejkob: but the mails sent will be delivered, or one need to wait, and re-submit? <NieDzejkob>The guix-patches archives look like it got clogged at about 10:00 yesterday <lfam>Hey efraim: For your recent commit about msmtp, is it supposed to say "instead try tp ing debian.org"? <lfam>guix-vits, NieDzejkob: It seems like the GNU mailing list / debbugs infrastructure is broken at the moment <lfam>I'm not sure who is responsible for that stuff or if they know... <efraim>lfam: and I wasn't even drinking <efraim>really should've been 'try to ping debian.org' <lfam>I guess you'd better start! <efraim>is anyone using mbsync with mcron or shepherd? <nckx>NieDzejkob: You can still use the ‘gnu: foo: Update to 0.0.0-1.abcdef9’ notation for git packages, by the way. <efraim>emacs-discover-my-major has disapeared from upstream <efraim>nckx: oh, I was looking at the one in the repo <nckx>Indeed, I just spotted that my URL has your URL in the README. <NieDzejkob>though they usually say "fork of ____" just under the repo name at the top ***nckx is now known as SecondChoiceNick
***SecondChoiceNick is now known as nckx
<mehlon>wow! I can't believe you were secretly SecondChoiceNick! <nckx>mehlon: That's just my legal name; I prefer nckx. ***NieDzejkob is now known as SecondChoiseNckx
***SecondChoiseNckx is now known as NieDzejkob
<NieDzejkob>the people reading logs.guix.gnu.org are gonna be *so* confused :P <mehlon>wow! I can't believe 420000 people just entered this room and left! <sarg>I've removed guile and installed guile-next instead. Now in my etc/profile there is no GUILE_LOAD_PATH. I can see `search-path` in ~/.guix-profile/manifest though. How is that possible? <NieDzejkob>sarg: I think GUILE_LOAD_PATH will only be set if you have other guile modules in your profile to load <lfam>Hey efraim, so about that msmtp thing. Having it depend on netcat was no good, but why does it need to test the connection at all? <efraim>lfam: we could just have it skip testing the connection, but by default it does test <lfam>But it wasn't testing previously, right? Unless you had netcat? <lfam>I know about this script but I'm not sure how it really works. Could it get stuck if it doesn't test? <lfam>It's not a big deal. I had worried about the case of Guix VMs which, by default, don't have ICMP. But those VMs also can't accept incoming connections... you probably wouldn't use one for mail. I'm not sure what's best... <lfam>Yes, I read that section <efraim>I figured i'd rather it fail to connect than spew errors if there's no connection <efraim>and rather ping debian than 8.8.8.8 <lfam>I use Mutt, mbsync and msmtp for my mail. It's okay. I hate that Mutt doesn't warn me if mail fails to send. I have no idea there is a queue in msmtp <efraim>I assume netcat would be able to make it through, no idea about bash sockets <lfam>And when you come back online, it doesn't get sent automatically but just sits there forever while you wonder why nobody replies <efraim>my internet has been spotty since we went into lockdown so I started trying out msmtpq <Blackbeard>lfam: mu4e does warn me. In case you want to give it a try <lfam>I've heard mu4e is great. I even use mu for searching my mail. But I'm not going to start using Emacs now :) It's too late for me <cbaines>janneke, I though I'd give building hello on the hurd a go as well <mbakke>lfam: join the dark side, evil mode ain't that bad ;) <cbaines>I've managed to hack it enough that I can run guix build now! <lfam>Maybe when I stop moving this Debian hard drive from laptop to laptop... I will also change editors <efraim>bumping tesseract-ocr is beyond my interest for tonight, making it use git-fetch will have to suffice <cbaines>mbakke, no, but that matches up with some of the stuff I did. I had to sort some Debian repository stuff, including building a Debian package for guile-ssh (not packaging it, just building the existing package) <Blackbeard>mbakke: I've heard great things about Emacs Doom, perhaps lfam could find it good enough for email <cbaines>janneke, I'm using wip-hurd, I assumed that made sense <cbaines>mbakke, I now see those instructions include building guile-ssh! <janneke>cbaines: please, update `THE-HURD' as you discover things <cbaines>janneke, out of interest, do you have a system service for the guix-daemon working? <cbaines>I tried, but didn't maange it so far <janneke>no, (as described in `THE-HURD') i start it by hand <nckx>Blackbeard: Do you have mu4e set up to queue outgoing mail? I never got that to work reliably, which was worse than not working at all. <lfam>Don't send mail to <NNN-reopen@debbugs.gnu.org> 🤦 <lfam>Looks like that broke the server <lfam>I guess you have to send reopen commands using control messages <Blackbeard>nckx: I don't send that many emails usually one or two a day. So I've never needed something like that <nckx>No, it's just that I prefer sending e-mails on planes & trains & other mobiles and never knowing if they'll arrive is something of a downer. <lfam>What do you use instead nckx? <nckx>Home-brewn horribleness. <nckx>‘Loop through the mail dir, ooh something to send, let's call sendmail.’ <cbaines>I run opensmtpd locally, and Emacs sends mail through that <cbaines>The few times things have got stuck, I've usually managed to figure out the opensmtpd commands to unstick it <nckx>I love OpenSMTPd on my server but permanently running it on my laptop seems so anachronistic. <nckx>It's a good work-around though. <nckx>Blackbeard: 🙂 Better every day. Can't complain. <nckx>Blackbeard: And you? Not too disturbed educationally/professionally? <Blackbeard>nckx: no, I am locked in my bedroom. My school was already online. <mehlon>well, good thing the world is already a digital simulation <Blackbeard>mehlon: yeah, now everything is going to stay online <nckx>Blackbeard: Hehe, thanks, I certainly agree 😉 <Blackbeard>Government always said 'moving everything online is too expensive and difficult' <nckx>Both my jobs are now illegal (‘going fast in very non-essential ways’). I've never read so many programming-related books in my life. Got to have a plan B. <mehlon>maybe you can watch an MIT lecture for free on youtube <nckx>If SICP counts: doin' it. <nckx>mehlon: Thanks, that's on my list too! Did you finish it? I've heard good things about both. Haven't run into a wall with SICP yet. <nckx>I much prefer these abstract ‘how to programme’ books to hands-on ‘how the javascript real gud’ stuff. That might come back to bite me. <nckx>drakonis: Interesting description. <mehlon>well it's actually readable both in formatting and in content <mehlon>and it doesnt waste my time too much talking about extended hyperbolic group algebra since I don't care about that <nckx>One day you'll need hyperbolic group algebra in your bash script and you'll be sorry. <mehlon>hopefully I'll have a perl library for that by then <nckx>sarg: Oh cool, imma snarf that. <drakonis>there's a paper by the authors regarding that <Blackbeard>And I think both have different purposes and they overlap a bit but not much <apteryx>has anyone tried powerline adapters? I have to choose between investing in a better WiFi adapter vs that technology. I'm a bit disliking the fact that it turns your apartment into an RF emitting source, but if it's the next best thing to cables... <Blackbeard>I understand that SICP is harder to read, at least it was for me, but the lectures are fun and easier <joshuaBPMan>Does anyone else have problems with ungoogled-chormium-wayland package crashing when you try to paste into it? <guix-vits>joshuaBPMan: if you start it from terminal, what does it prints? <vagrantc>tried a few days ago and it just crashed immediately <nckx>Blackbeard: If anyone were to ask, I'd recommend against reading SICP without watching the lectures. It was designed as one course, and it shows. <joshuaBPMan>I do see some start up errors. "Failed to connect to the bus". <joshuaBPMan>then I've got a ton of error messages. Let me paste it. <pinoaffe1>is there a guix command line option to get the store location of an installed package? <sarg>pinoaffe1: guix package -I <drakonis>its not april fools yet, why was magit removed? <nckx>The games in question were briefly renamed to very verbose names. We decided to revert them, but the very-long-names were kept as deprecated packages just in case someone had installed them during that short window. <Blackbeard>nckx: I think I will submit my gsoc proposal now, would you give it a look? <vagrantc>can you define multiple agetty-service entries? <vagrantc>or do you have to mark them differently somehow? <nckx>Blackbeard: Sure. g_bor[m] is our actual GSoC liaison IIRC. <civodul>mbakke: re GNOME Terminal, great that there's an explanation! :-) <mbakke>Phew, Timotejs SDL work in #40211 looks great, but I'm too exhausted to review more "heavy" patches right now :-/ <nckx>Blackbeard: Looks good. Not going to bother with grammar (unless you want me to) and I don't see anything implausible in your road-map. I don't agree that being a CS student == being (more) qualified, by the way. 🙂 <nckx>It's ambitious, but that's fine for GSoC. <mbakke>oh no, merge conflict from the module import reordering in admin.scm <nckx>But defer to g_bor[m] who has more experience with these things. <nckx>In hindsight I should have delayed that until after the merge. <efraim>or cherry-picked it to the other branches <nckx>mbakke: Which branch(es)? I'll fix it up. <mbakke>nckx: on the core-updates branch, but please don't push anything as I'm in the middle of a merge :D <mbakke>nckx: it's okay, you could not have known :) <mbakke>also, these things are some times unavoidable <nckx>No, but I could've kept my finger closer on the pulse recently. <nckx>All this exciting stuff. <nckx>1.0.2 is going to be one awesome release! <mbakke>weird, I can't find anything in the commits logs that indicates there have been changes to the module imports, hm <leoprikler>Odd = unstable, even = stable, or just incrementing? <leoprikler>so the next release would technically be 1.1.0 if we went full semver, right? <nckx>Semver doesn't make sense for Guix, but yeah, probably. <lfam>We don't have anything to semantically version <ngz>I think we do. The API of the guix command. <leoprikler>I'm not too sure about that. The daemon and build system APIs would count imo. <nckx>And we don't do the (as in, any) housekeeping during development to say with any confidence at release time what will break. If (say) your channel has been tracking 1.0.1 for a year, it's a pretty useless channel. <nckx>leoprikler: Those are implementation details that aren't versioned. <leoprikler>Those "implementation details" are the things a channel (say it is tracking 1.0.1 for a year) is relying on though, more so than the package descriptions. <mbakke>vagrantc: if you are around, please delay the mesa patch on core-updates until I've finished my tests (maybe 20 minutes) :-) <nckx>Coming from NixOS I found Guix's (then) 0.x releases quite quaint. Now I know it's just a sham! *mbakke needs a faster computer for faster merges <nckx>leoprikler: Channels should always track master, I think we're quite explicit about that in the manual. <leoprikler>But still, if you're tracking master, you somewhat rely on things not breaking most of the time. <lfam>It's good motivation to add the things to Guix <leoprikler>I think I remember a channel, that must not be named having some difficulties resolving a deprecated qt dependency for a few days. <leoprikler>lfam: Ideally that's what one would do, but there are things that don't quite fit into Guix. <vagrantc>mbakke: oh, i hadn't even tested it yet myself :) <vagrantc>mbakke: but happy to hear it's up for consideration :) <lfam>I don't think anyone is breaking things on purpose, but we've always resisted having an API because it makes Guix development so much simpler <vagrantc>or rather, haven't done more than build-testing <starcrATI[m]>Hey guys, I have another problem ^^ i3lock won't let me login again once I've locked my screen ... anybody experiencing the same issue ? <leoprikler>I think I dealt with something close to that once. <leoprikler>Okay, I remember again, it might be a PAM issue. <leoprikler>You should be able to resolve it by having i3lock as a screen-locker-service. Did you do that? <starcrATI[m]>leoprikler: huh no, I didn't, thank you ... I'll try to set that up :) <NieDzejkob>oh, and make sure you run the i3lock from /run/setuid-programs <mbakke>vagrantc: I think the testing you mentioned in the bug report is sufficient, i.e. the new drivers appear in the output <leoprikler>Yeah, you probably should not install i3lock in your user profile. <nckx>We haven't rolled out the telemetry module yet, but I think that a strict majority of ‘things that don't quite fit into Guix’ suffer from a distinct lack of freedom if we're honest. <nckx>I am 100% OK with not complicating Guix development even a smidgen on their behalf. <civodul>janneke, dongcarl: on master, "guix build gmp --target=x86_64-w64-mingw32" fails to build due to an #include_next <stdlib.h> in C++'s <cstdlib> <janneke>i believe it's fixed on core-updates; i only know of an ugly workaround <civodul>i'm asking because currently etc/release-manifest.scm expects it to build <civodul>perhaps we can cherry-pick that fix from core-updates <leoprikler>wouldn't telemetry kinda beat the purpose of freedom, though? <janneke>civodul: ah, believe no core-updates has a proper fix; this is about the CROSS_ path story, right? <Blackbeard>leoprikler: in my opinion it doesn't, if done right <Blackbeard>Syncthing has telemetry but they show you an example of what they are collecting and why <leoprikler>In my opinion, "telemetry done right" is bug reports and only bug reports. <mbakke>uff, tests/guix-package.sh fails due to "no matching pattern" from guix/ui.scm:1936 <nckx>leoprikler: Twas a joke. <leoprikler>But yeah, the only free software you won't ship with guix is stuff that's too niche. <janneke>hmm, i'm having trouble building master -- i think i saw this before <janneke>error: failed to load 'guix/scripts/pack.scm': <janneke>ice-9/eval.scm:293:34: no binding `zip' to hide in module (gnu packages compression) <leoprikler>That one usually shows up if some other thing breaks first. <leoprikler>Perhaps a malformed module or something like that. <vagrantc>mbakke: have the tests you were doing completed? e.g. can i push the mesa patch? <mbakke>vagrantc: I'm aborting the merge, so go ahead! some strange hidden conflict somewhere is causing an odd failure. <janneke>leoprikler: thanks, yes i made a typo *janneke was sure HEAD was hard reset...oh well <seepel>Hi guix! I am happily running Guix System, but just started looking into booting into my windows partition in order to update some firmware and test some other hardware related things that are bothering me, is this possible? (also sorry if this question is too non-guix, just let me know and I'll let it drop). <nckx>I don't think anything has changed, no. <nckx>Nope, we still explicitly require rigid menu-entry { linux …, initrd … } entries. <seepel>If I modify grub.cfg by hand to temporarily boot into windows will that bork the whole system? Or just be a change that gets wiped out the next time I reconfigure? <nckx>The latter, assuming you don't make a mistake. <seepel>ok, that sounds good enough for me. I don't really have a desire to regularly boot back into windows. Thanks nckx! *vagrantc still wonders about linux-libre 5.5.x ... <mbakke>I hope Mark is okay, he's been very silent lately. *nckx assumes everyone's just waiting for mhw to respond. <vagrantc>mbakke: silent, but pushing updates for older kernel versions <vagrantc>it's getting frustrating to have to rebase the 5.5.x series for new versions <nckx>seepel: In your (well, I'm madly substituting ‘FreeBSD’ in my head to stay happy 🙂 ) case I'd just boot manually using the GRUB command line. It supports the same syntax as grub.cfg. <vagrantc>alternately, i can push the source for 5.5.x and then just build select kernel image packages against it <seepel>nckx: Even better! And I'll make the same substitution in any further questions :) <mbakke>vagrantc: as a general note, always run 'make oldconfig' when updating the kernel configuration for a new minor (or major) version, I noticed in your message that you were re-using the old config <vagrantc>mbakke: i re-used the old config and then updated it from the produced one ... is that not right? <vagrantc>as it basically runs make oldconfig as part of the build <mbakke>vagrantc: otherwise the kernel build system will choose defaults for any new or changed options, which may not be desirable <vagrantc>oh, i was thinking of the debian packaging ... <mbakke>vagrantc: make oldconfig is interactive <mbakke>there is a "silentoldconfig" that runs regardless <mbakke>IIRC there was a tricky question when I updated my kernel to 5.5, don't remember which though <vagrantc>so, to run "make oldconfig" i'd have to check out the source, copy the file into .config and run make oldconfig? <nckx>seepel: Oh: you may or may not have to type ‘boot’ at the end, my memory's hazy on that point. Anyway, you'll figure it out. Good luck. <pkill9>is guix installed as a system package by default in guix system? <pkill9>i'd like to install a symlink in /run/current-system/profile/bin/guix to root's guix <nckx>pkill9: You only use it once, to pull a fresh one, but it's there. <vagrantc>maybe i'll make one more patch series update against 5.5.x <seepel>nckx: Thanks, yeah I plan on triple checking the documentation <vagrantc>since the pinebook pro stuff is in there, it should make the patch series shorter <nckx>pkill9: So ln -s /root/.config/guix/current/bin/guix (or /var/guix/profiles/per-user/root/…) /run/current-system/profile/bin/guix ? <pkill9>for when i create temporary users <pkill9>but i can just make a script or something <pkill9>to symlink their current guix to mine <nckx>Hm. How horribly out-of-date are you planning on letting your system get? (Forgive my Englishes.) Isn't that the real problem? Or do you really need an up-to-the-minute rootguix. <mbakke>pkill9: you can also use 'guix pull -p /var/allusersguix' and make sure that directory appears first in PATH <mbakke>the -p destination can be anything, of course *mbakke signs off for tonight, good night/day everyone :-) <pkill9>the solution is to modify /etc/profile maybe, to change the default $PATH, i know it's created by a service in guix <pkill9>anyways im mostly just bikeshedding