<fnstudio>lfam: right, in terms of `guix environment`, that's actually interesting but also something i'm not sure i fully understand <fnstudio>if i create an env with `guix environment` and then `pip install -r requirements.txt` into it... is that going to be isolated from the rest of the system? <fnstudio>does using `guix environment` also incapsulates the python dependencies of a certain project? <lfam>Yes, that's what it does <lfam>If you were working on a package called foo, you would do `guix environment foo`, and it would put you in a development environment for foo, including its dependencies <NieDzejkob>you'd have to do guix environment --ad-hoc python-foo python-bar <lfam>I've never used pip or pipenv or Python virtualenvs, so I can't compare them <fnstudio>NieDzejkob: if i create a guix env like that, do i still need to create a python env? or can i simply and directly `pip install` stuff into my guix env and then that will be kept separate from my other guix envs? <fnstudio>NieDzejkob: or rather, what you're saying is that `guix env... python-foo` replaces `pip insall python-foo`? <Noclip>fnstudio: It replaces pip install but works only if python-foo and python-bar are existing guix packages. <Noclip>For example "guix environment --ad-hoc glances" will put you in an environment that has glances installed. There is no need to install glances with pip anymore. <fnstudio>Noclip: thanks, yeah, that's the point that i find problematic... it wouldn't work in a (very common) scenario where i need to `pip install` the dependencies of a project from its `requirements.txt` <fnstudio>unless all such dependencies have been packaged and i manually "convert" the req.txt file to the corresponding list of guix packages <Noclip>fnstudio: Do you know the pypi importer? It lets you create guix packages directly from pypi. <fnstudio>Noclip: uh... no, i don't, let me see, is it in the guix docs? <Noclip>fnstudio: Yes the command is called "guix import" or in this case "guix import pypi". <jonsger>str1ngs: even the cached narinfo seems good /var/guix/substitute/cache/4refhwxbjmeua2kwg2nmzhv4dg4d3dorpjefq7kiciw2pfhaf26a/0ivha10k6zq4jkx1730087i9sa5xyp22 <fnstudio>Noclip: thanks, that's definitely helpful <nckx>Berlin offloads are still throwing Throw to key `match-error' with args `("match" "no matching pattern" #<eof>)'. ☹ <nckx>raghavgururajan: Wouldn't that be extra_link_args? (extra_link_args = ["-Wl,-rpath=/gnu/.../lib"]) <nckx>In general, I'd use substitute* for that, unless the setup.py has some mechanism to set them. <jonsger>that's strange: after I built a package on another machine, which downloaded it from ci.guix.gnu.org and I removed the substitute cache on my laptop, it finally downloaded the substitute instead of building it locally... <raghavgururajan>The bottom-line is that the python files, upon excecution, could not find .so files. <jonsger>okay, it's super akward but it works <jonsger>I now either need someone who can look at the logs of ci.guix.gnu.org or some HTTP debugging within guix <nckx>jonsger: What needs to be grepped? <nckx>raghavgururajan: Hm, extra_link_args would be added to an Extension() passed as setup(name="louis", ..., ext_modules=[the_extension]). But that setup.py.in doesn't use ext_modules at all. There's nothing being C-compiled so -Wl,-rpath= is pointless here. Are you sure rpath is the issue? <nckx>I'll read __init.py__ in a moment. <fnstudio>Noclip: sorry, i'm still thinking about pip/guix... import a pip package into guix seems to be very straightforward, but than how come some python packages such as virtualenvwrapper or pipenv are not in guix? is it because that'd imply some extra maintenance effort? <nckx>raghavgururajan: Is ‘liblouis = _loader["###LIBLOUIS_SONAME###"]’ what fails? <nckx>Which is monkey-patched in the Makefile to point to liblouis.so. Maybe monkey-patching it further to be an absolute file name will work. <nckx>I don't know squat about CTypes. <nckx>And all this is assuming it really is the Python module at fault, and not (say) the library missing an rpath. <Noclip>fnstudio: Also guix is a very young package manager so there are still a lot of packages missing in the main repository. <fnstudio>Noclip: sorry, just seen your last message, amazing, great recap, thanks so much! <fnstudio>Noclip: yeah, that clarifies things a lot <vagrantc>what is the default value for guix-daemon --max-jobs ? ***jonsger1 is now known as jonsger
***catonano_ is now known as catonano
<apteryx>could someone tell me what's the guix commit being used for the system on bayfront and berlin? <nckx>apteryx: berlin: 7f765a9d9c21ea3c0e5426795ae909f1e3c7e0a7, bayfront: not sure, why? <nckx>20cc8f9487e949ed2d314219cc828c3663d4f12b <nckx>but I don't know if bayfront's guix-daemon &c. were restarted after. *raghavgururajan is suprised that nckx is still awake *nckx nckx is always surprised--er, awake. <apteryx>curious to know if it already has the patch to use 'systems' instead of 'system' for the build-machine records. <apteryx>and bayfront is even more behind (it's nearly a month old it seems!) <str1ngs>I don't like meson. Make Error at /gnu/store/89rj5fqcg48afgk99639ds602pgf92k4-cmake-minimal-3.16.5/share/cmake-3.16/Modules/FindPkgConfig.cmake:467 (message): <str1ngs>that is the least helpful error ever. <str1ngs>later tell guix-vits. iwd also fails to build on my jetson nano SBC. not sure who you got around that unless you got lucky with a substitute? <str1ngs>sneek later tell guix-vits. iwd also fails to build on my jetson nano SBC. not sure who you got around that unless you got lucky with a substitute? <apteryx>nckx: by the way, "guix" now work for usertags on Debbugs! The maintainer unearthed the "why" it'd work for emacs and not guix and made a fix on the Debbugs instance side. Now any registered GNU package name should be allowed. <str1ngs>I might just need more RAM. Swap: 26Gi 18Gi 8.6Gi <str1ngs>currently I'm using zram. but I technically 16GB is not enough for 24 cores and building webkitgtk <str1ngs>I don't now how my machine is still running. but I don't want to stop the build to lower the --cores haha <apteryx>str1ngs: I think I managed to build webkitgtk last time with my 8 GiB machine (6 GiB configured as ZRAM). <apteryx>it probaly used about 12 GiB of RAM, IIRC. <str1ngs>lower cores does help with ram. though decrease build time of course. <str1ngs>I'm using 12 cores with 12 threads so I'm kinda pushing my luck with 16GB of ram. <brendarn>i tried building chromium with 32gb of ram and 10gb swap and it still failed saying cant get a temporary file <str1ngs>I'm building with --cores=12 now I have been meaning to buy more ram ***apteryx is now known as Guest65684
***apteryx_ is now known as apteryx
<Noclip>Is it possible to use "guix system container"-scripts without root privs? ***brendyn is now known as brendyyn
***sneek_ is now known as sneek
<sneek>guix-vits, you have 1 message! <sneek>guix-vits, str1ngs says: iwd also fails to build on my jetson nano SBC. not sure who you got around that unless you got lucky with a substitute? <guix-vits>str1ngs: No, i just live without Network Manager for a mean time. idw fails to build, too. (aarch64) *guix-vits battle-epic.ogg <raingloom>did someone remove NetworkManager from %desktop-services? ,:| <raingloom>i reconfigured last night and when i booted today i did not get an IP through DHCP. <raingloom>but adding it manually results in a duplicated "networking" entry, so this is fishy. <guix-vits>raingloom: Is nmcli available in Your shell now? <raingloom>....oh right, the reason i didn't see it in `herd status` is because it's not called "network-manager" or anything similar. <raingloom>hold on, i think i'm too hungry to debug this. gonna get back in a bit. <raingloom>something is definitely up but i don't know if it's guix related. <Noclip>It is not possible to use "guix system container"-scripts without root privs, is it? <sneek>g_bor[m], you have 1 message! <sneek>g_bor[m], raghavgururajan says: You email address is your lastname at gmail dot com, correct? <brendyyn>I like how emacs-minimal is an entire 400KiB smaller than emacs, and I apparently need both of them. <jlicht>brendyyn: afaik, emacs-minimal's "minimal" rather refers to the `guix size emacs-minimal', not to the actual program itself <jlicht>for me, emacs{,-minimal} difference there is a bit more than one GB! <efraim>gnupg has ~340 dependencies, still ok to push to master? I don't think we want it to be a staging package <g_bor[m]>efraim: I tend to agree. gnupg is quite secutiy critical. Are there any big deps? <efraim>Building the following 190 packages would ensure 342 dependent packages are rebuilt <efraim>looks like a lot of leaf packages <Kimapr[m]>okay i see i should make a git repo for this <Noclip>Holy shit, my Guix is completely broken! Guix itself, the guix-daemon and even all the packages that had been installed with guix don't work anymore! <Noclip>It's always the same: "-bash: /home/administrator/.guix-profile/bin/hello: No such file or directory" <kmicu>It could be a path/linking issue if ls still lists /gnu/store/*-hello* <Noclip>Or in the case of any guix command: <Noclip>"-bash: /home/administrator/.config/guix/current/bin/guix: /gnu/store/0w76khfspfy8qmcpjya41chj3bgfcy0k-guile-3.0.4/bin/guile: bad interpreter: No such file or directory" <Noclip>kmicu: The hello binary exists and I can even copy it out of the store but it still keeps failing. <kmicu>Did you try in a fresh shell? Maybe guix in your current shell points to old versions. <Noclip>Could it be a low level dependencie that has turned corrupt? <kmicu>If stuff is still in /gnu/store then it’s probably a misconfiguration when guix commands in your shell cannot see it. <kmicu>Does /gnu/store/0w76khfspfy8qmcpjya41chj3bgfcy0k-guile-3.0.4 exist? <guix-vits>Noclip: If that an Guix as package manager installation? What about SELinux? <kmicu>SELinux would rather prevent Guix from working before. <guix-vits>kmicu: maybe policy was disabled by some update, IDK :) <Noclip>kmicu: Yes, it's a 54M directory with several binary files in the bin folder. <Noclip>guix-vits: Yes it's just a package manager installation. Everything related to the foreign distro works just perfectly fine. <kmicu>So it broke after you executed guix system container as root? No system updates in your native os in the mean time? <Noclip>I didn't update guix (at least not at the real system). But I did something else: <kmicu>Checking ‘ls -al $(which guix)’ and GUIX related envars in your path could help with narrowing down the issue. <Noclip>I executed "guix pull" in the guix system container. <Noclip>I used the option --commit to pull it to the exact same commit of my default user account. <kmicu>Maybe it’s matter of exectuing ‘hash guix’ to fix the issue but I assume you’ve tried a fresh shell already. <Noclip>kmicu: I've already restarted my host os. <Noclip>Is "guix pull" inside a system container a bad idea or should it work normally fine? <g_bor[m]>civodul: I wass contacted by Outreachy, if guix is willing to participate in the winter round. <g_bor[m]>Recently I was a bit overwhelmed, but now I got some free capacity finally :) <Noclip>guix-vits: Can you point me to a specific log file that I could search for SELinux errors? <guix-vits>Noclip: No, i just bla-bla, sorry. journalctl? <civodul>g_bor[m]: ah yes, i saw your message! <civodul>we'd have to discuss it, but why not <civodul>g_bor[m]: it'd be nice to have a post about what raghavgururajan has achieved too <civodul>there's an interview being worked on <kmicu>Noclip: I would double check Guix setup for example ‘env | grep GUIX’, PATH in your shell. <g_bor[m]>ok,we still have about two weeks to decide, I only need acknowledgement that we are willing to finance at least one intern. <Noclip>4 out of 4 "...-guix-command" binaries failed. Interestingly they do all point at "/gnu/store/0w76khfspfy8qmcpjya41chj3bgfcy0k-guile-3.0.4/bin/guile" in their error message. <Noclip>guix-vits: No it doesn't work for root. Even the daemon (which is started by systemd) failed. <Noclip>GUIX_PROFILE=/home/administrator/.guix-profile <Noclip>GUIX_LOCPATH=/home/administrator/.guix-profile/lib/locale" <kmicu>Where do you source $GUIX_PROFILE/etc/profile ? <Noclip>(That file has been created by the official install script.) <kmicu>It’s possible running guix system container unlinked something because executing guix system commands on a non‑Guix‑System disto is not a popular workflow. <Noclip>I would like to test the store for corruption but that requires a working guix installation ... <kmicu>(It would be nice to see PATH.) <kmicu>Noclip: are you able to execute ‘/gnu/store/*-helo*/bin/hello’ ? <kmicu>(double ll in the first hello) <Noclip>kmicu: That's my PATH: "/home/administrator/.local/bin:/home/administrator/.guix-profile/bin:/home/administrator/.config/guix/current/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin" <kmicu>(Store is mounted read only so I doubt there is any corruption only that somehow guix tools cannot see the store.) <Noclip>kmicu: No, running hello fails, no matter how I invoke it. <kmicu>(We can invoke hello by executing ‘/gnu/store/*-hello*/bin/hello’ in shell.) <Noclip>"-bash: /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10/bin/hello: No such file or directory" <kmicu>But /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10/bin/hello exists in the store? <Noclip>What happens if you isolate the hello binary from the rest of the store and try to execute it? (For example with "guix environment -C ...") <Noclip>"-r-xr-xr-x 2 root root 37832 Jan 1 1970 hello" <leoprikler>so... this is a really minor issue, but the .desktop file for emacs 27 appears a bit broken *kmicu now thinks guix-vits was right about SELinux kerfuffle. <Noclip>kmicu: The hello file starts with the bits "45 4C 46" and ends with "00 00 00". *Noclip knows nearly nothing about SELinux. <leoprikler>basically emacs -> emacs-27.1 -> .emacs-27.1-real, but the latter is not seen as "emacs" and hence not associated with emacs.desktop <kmicu>Then it could be AppArmor but I’m not familiar with Mint. <Noclip>When I installed guix (several weeks or month ago) I didn't mess with those SELinux settings as guix just worked. And it keept working until a few minutes/hours ago. <kmicu>Internet says something about ‘sudo aa-status’ to check its status. <g_bor[m]>you should be able to getenforce to check the selinux status <Noclip>But does this make really sense if everything worked fine before? <g_bor[m]>I don't think so, but it doesn't hurt either, <Noclip>The guix system container can communicate with the daemon and the daemon has wright access to the store, right? So maybe the daemon has broken something while trying to serve the guix pull request of the container? <g_bor[m]>if it is not in enforcing mode, then we can be sure that's not it <kmicu>You clearly have hello in gnu store but when you use absolute path then shell says no such file or directory. <kmicu>(That’s a common error for SELinux/AppArmor issues.) <kmicu>When we use absolute path to the store we bypass guix tools so it doesn’t matter wheter they work or not. <kmicu>I cannot find anything related to AppArmor on the issue tracker 🤷 <Noclip>"When we use absolute path to the store we bypass guix tools so it doesn’t matter wheter they work or not." <Noclip>Do want to say that it can't be an SELinux/AppArmor issue if the absolute path doesn't work? <kmicu>Noclip: I’m saying it probably is. Maybe you could try aa-teardown <kmicu>to turn it of and then execute /gnu/store/*-hello*/bin/hello <kmicu>I'm out of ideas so I hope someone knowledgeable about Debian(‑like) systems can help. <Noclip>There is no aa-teardown command on my system?! <g_bor[m]>if this is a machine where you can experiment freely, you can try a systemctl stop apparmor <Noclip>g_bor: It's my main production system but a systemctl stop shouldn't hurt. <jlicht>does anybody happen to have a packaged version of `bmake' lying around :-)? <Noclip>Looks like selinux wasn't enabled at all: setenforce: SELinux is disabled <apteryx>For package that contains both python libraries and python based scripts, do we always prefix with python- or do we choosed based on what we think is the main use of the package (e.g., if it's calling an eponymously named script) ? One example is python-cantools. In other distribution it seems more common to be named 'cantools'. <apteryx>another is python-git-review, which provides the 'git-review' script. <leoprikler>main purpose, though that's usually a bit gray vs. grey <leoprikler>also if there are other implementations e.g. ghc-git-review it would make sense to have the python prefix <apteryx>good points! For the multiple implementation cases, I guess it could be argued for that the original implementation gets the original name. <jlicht>Is `package/inherit' preferred compared to `(package (inherit ...', or are there situations in which this is not the case? <leoprikler>there is a difference in what they do and my personal preference is to use the latter unless I need the extra features of /inherit <apteryx>nckx: by the way, I think you were curious about what code runs as the Debbugs GNU instance? <jlicht>leoprikler: how are they different then? As I understood it, package/inherit is the same, except that it makes sure that things still works with replacement packages. Am I misunderstanding something? <leoprikler>"things still works with replacement packages" is a bit simplified imo <leoprikler>it's whether or not you want to automatically get graft packages or not <bdju>Sway is crashing A LOT for me lately. I think 4 times in the last 48 hours <Noclip>kmicu: What output do you get from this command: "cd $(lh $(which hello) | awk '{print $11}' | sed -E 's/\/bin\/hello *//') && guix environment -C -- ./bin/hello" <Noclip>@Oh wait, I have put my alias "lh" in there ... 🤦 <Noclip>"cd $(ls -Al $(which hello) | awk '{print $11}' | sed -E 's/\/bin\/hello *//') && guix environment -C -- ./bin/hello" <kmicu>Why do you want to test guix enviroment -C if even basic guix doesn’t work for you? <Noclip>kmicu: No, I want you to test it for me, because I can't do it. <civodul>nckx: re mailutils on aarch64, you emailed bug-guix-owner instead of bug-guix <Noclip>kmicu: It should basically just isolate the hello programm from the rest of the system and run it then. <Noclip>This should show us wether hello depends on other store items and how the system reacts if those are not available. <Noclip>Could anyone please execute the line I posted above and send me the output message? (It requires the hello package to be installed through guix.) <kmicu>Noclip: it just works. It prints Hello. (But don’t cd into store or touch store in anyway.) <Noclip>kmicu: Thanks! That's really weird. How can it then not work for me? <raghavgururajan>> civodul: g_bor[m]: it'd be nice to have a post about what raghavgururajan has achieved too <raghavgururajan>I will be writing a blog post to summarize the work. I am waiting on Oliver's post to be published first. :-) <kmicu>Noclip: why would it work if even executing hello directly from the store doesn’t work for you? <Noclip>kmicu: But why does executing it directly from the store doesn't work? Even copying it somewhere else and executing it doesn't work. <kmicu>Probably because of apparmor as we discussed. Did you try stopping apparmor systemd unit? <Noclip>Didn't help. But I'm not sure if that really deactivated apparmore. However, why should AppArmor block a simple hello world binary? <leoprikler>how would you know it's just a hello world binary? <Noclip>kmicu: Did you really execute the bash line as I posted it? For some reason posting it in this chat removed the backslashes from the line so it shouldn't do anything. <Noclip>`cd $(ls -Al $(which hello) | awk '{print $11}' | sed -E 's/\/bin\/hello *//') && guix environment -C -- ./bin/hello` <Noclip>No this little bash script should work finally. <Noclip>leoprikler: What else should it be? <leoprikler>an evil virus threatening your security of course 😈️ <leoprikler>you think it's printing "hello world" while it's secretly inviting aliens from outer space to take apart your computer <civodul>raghavgururajan: yes, i was thinking about the interview! you can add g_bor[m] in the loop <Noclip>leoprikler: That's ofcourse why aliens would come here xD <kmicu>Noclip: one of jobs of systems like SELinux/Apparmor is preventing execution of binaries from random places so it makes sense you cannot execute a binary from a path not allowed by your distro’s policies. <Noclip>That's why I also copied it to another place. <guix-vits>vagrantc: IDK those matters, and if i'll be able to do anything with this on my own, so report: on RockPro64 i have good video on linux-4.4 with Armbian patches (on Armbian), but for Guix and Armbian with 5.8 kernels, i have "distorted" console, and sway works good only in 1280x1024. <hendursaga>Glad Emacs 27.1 is finally packaged! Almost went without a hitch! <Noclip>kmicu: Ram Disk. I'm just executing there a lot of random binaries right now ... <kmicu>And it gave the same erros message that file or directory does not exist? *kmicu had only some issues with font caching after jumping into 27.1. <Noclip>Ohhh, look at this, a fresh guix binary inside an alpine proot environment seems to work fine! (In my Ram Disk of course ...) <str1ngs>guix-vits: I think for kernel 5.8 series you'll have to see what Manjaro does re rockpro64 <guix-vits>str1ngs: on the 5.8, Manjaro have same issues for me. <str1ngs>really, strange usually it's the most supported. <guix-vits>Seems for _me_, that either the newest kernels lacks some patches, either this is related to my monitor (new bugs/features). <Noclip>Shit on HDDs/SSDs, I'm now installing guix in my Ram Disk! 😂 <guix-vits>Noclip: Don't allow those Guixen fool You: use Puppy Linux. ***Digitteknohippie is now known as Digit
<Noclip>Wait. So why exactly am I not just using the install script inside the proot system? <Noclip>Might make my life much simpler. <vagrantc>guix-vits: armbian frequently applies various patches that may never get into mainline for various reasons ... but they do sometimes work! <sneek>Welcome back vagrantc, you have 1 message! <sneek>vagrantc, raghavgururajan says: IIRC, the value is 4. *vagrantc wonders if that was in the earlier discussion on legal values of pi <str1ngs>Noclip: you want to use guix inside a chroot? <guix-vits>blackbeard[m] did some guix-chrooting recently? <Noclip>str1ngs: I want to proof that my system can still run guix in the first place. <Noclip>str1ngs: That's what I did all the time before guix just broke today. <vagrantc>there's a thread about upgrading to emacs 27.1 on the list ... <Noclip>And by "it broke" I mean it completely broke! <Noclip>Everything that had anything todo with guix just stopped completely working ... <str1ngs>Noclip: do you have more details then "just broke" does guix-daemon not start? is there an error message? <fnstudio>hi guix! there seems to be something wrong with my setup (or with my understanding of `guix environment`); if i run `guix environment <package>`, the package gets downloaded and then i'm let into a new environment but there doesn't seem to be trace of the command just installed <str1ngs>fnstudio: you need to do guix environment <package> --ad-hoc <package> <Noclip>str1ngs: I think the chat history is logged, right? I already discussed it for several hours so you might just want to look it up in the logs. <str1ngs>fnstudio: guix environment is a build environment --ad-hoc adds the package to the environment provile. <str1ngs>fnstudio: probably you just want guix environment --ad-hoc <package> for simplicity <Noclip>I'm actually interested if the install script will work in a proot system. Let's see xD <fnstudio>str1ngs: hm right, sorry, i should have spotted that in the docs! <Noclip>str1ngs: I was to lazy (or busy?) for sleeping last night 😂 *str1ngs sips his americano <Noclip>I said that I was to lazy to go to bed last night so I'm still awake ... <Noclip>I'm also not yet tired. So why going to sleep then? <str1ngs>I take it proot is a program that pivots root? <str1ngs>personally I would avoid that layer of complexity. if you install guix on a foreign distro. it only touchs /gnu and /var/guix. it's pretty isolated and safe. <Noclip>It's basically chroot without needing root access to the host. But you can be root in the guest system with it. <Noclip>str1ngs: I'm doing this in my ramdisk right now. When I restart the pc next time, everything will be cleaned up xD <Noclip>But most likely I will clean it up my self even before restarting the pc ... <Noclip>And I forgot to give the script execution rights (+x) again ... <lfam>daemonspudguy: Can you give a little more detail? Which file? <lfam>You should be able to run `guix pull` and skip past that, if I understand correctly. The current version is 1.1.0-23.2f458ad <lfam>The "22" vs "23" being the relevant part <daemonspudguy>My internet sucks it will take a few millennia or something. <lfam>Sorry about that :( There was a mistake regarding the "22" version <nckx>Yeah, ‘guix hash -rx’ on commit 4b5a6fbc9b754c0ca70d033dd99f17c4f028733a returns a different hash here from what the ‘22’ package had. <nckx>I seem to have missed whatever happened. <nckx>daemonspudguy can pull or they can chat. *nckx forgot to say good morning Guix! <nckx>Hullo raghavgururajan. Did you get any further with liblouis? ***daviid is now known as Guest54789
<daemonspudguy>Came up with a new attack plan. I copied the scm file that was created for me to a second USB stick. So I'm now gonna try to use that with GuixSD stable. <raghavgururajan>nckx: I am taking to liblouis devs. Still trying to figure out some things. <raghavgururajan>nckx: To precisely show you the issue, if you have bootstrapped wip-desktop, could you run 'orca' in a pure-env with ad-hoc of orca gnome-desktop and dbus? <str1ngs>lfam: hello, which branch should I use for gtk-next if you will? I'm doing some work on webkitgtk and I don't want to duplicate effort. <lfam>Good question, str1ngs. It depends on a couple factors <lfam>If you do `guix refresh -l gtk+`, it will tell you how many packages will be rebuilt if you change the gtk+ package. If it's more than 300, it can't go on the master branch <str1ngs>lfam: I'm not to worried about rebuilds. I just want to make sure the packages I'm upgrading have not already been up upgrading <str1ngs>though some of this experimental but I do have some quality of life improvements I can weave into stable say webkitgtk <lfam>I would check the gnome-updates-3.36 branch to see if it has the same work or not <str1ngs>also I'm doing some work on gstreamer <str1ngs>lfam: great thanks will look into thanks. <lfam>It's part of the util-linux package <pkill9>what could be causing this error? guix build: error: regular file expected *pkill9 really needs a commandline paste uplaoder <pkill9>i think it's the local-file part <nckx>I'm bootstrapping it on my laptop. However, I'm running Sway (Wayland), I have no idea what extra bugs that could add. <nckx>Some things fail to launch since I've switched, and many things are still a bit ‘off’. <str1ngs>hello I'm having trouble getting this substitute-keyword-arguments snippet to disable tests the expression is valid but it still tries to run tests. http://paste.debian.net/1161621 should I just delete the check phase? <nckx>Right, I know Gnome supports Wayland, but I don't know if it supports non-Gnome Wayland well 🙂 <nckx>It's the screen reader, right? <jsoo>vagrantc: do you have a configuration for rock64? I am hoping to setup the guix system on a pinebook pro soon <str1ngs>nckx: I still can't switch to due to how bad emacs looks. do you have a HiDPI screen? <nckx>str1ngs: Could you paste the entire package expression? What you pasted looks OK (super-nitpick: s/var/_/ for ‘unused’ variables like that). <str1ngs>nckx: funny I actually used _ then second guessed myself <daemonspudguy>jsoo: I believe the Pinebook Pro uses a different board than the Pine Rock64 <jsoo>guix-vits: Oh yeah! Is that on gitlab? <nckx>str1ngs: Maybe your standards for emacs/fonts are higher than mine: tobias.gr/emacs.png <str1ngs>nckx: probably (delete "-Ddoc=false" (delete "-Dgl=disabled" ,flags)) can be improved. but hey it works <str1ngs>I'm terrible grokking cut and compose <str1ngs>nckx: I'll keep plugging away at switching to sway. atleast kmonad works so that resolves my xcape issue. <pkill9>i wa sexpected local-file to function the same way as --with-input <nckx>str1ngs: Thanks, I'll poke at it intermittently between other tasks. <str1ngs>nckx: tests are running so it might just pass so this could be mote. <str1ngs>worst case I delete the check phase. but I'll like to use substitute-keyword-arguments more proficiently. <jsoo>Ok excellent. Thanks guix-vits ! <guix-vits>jsoo: elogind-service currently doesn't work with linux-libre-arm64-generic <guix-vits>jsoo: You'll need to add CONFIG_CGROUP_FREEZER=y to kernel's config. <pkill9>how do i use a directory with local-file? <guix-vits>jsoo: nckx say, that linux-libre (default) working on aarch64. <str1ngs>nckx: also regard to the body of the arguments in substitute-keyword-arguments sometimes they are quoted sometimes they are not. so bit confused as to whats going and should be used there. <vagrantc>jsoo: nothing special ... just used linux-libre-arm64-generic and no initrd modules <str1ngs>nckx: I just deleted check phase for now. I'll go back later see if I an fix the checks. <vagrantc>jsoo: not sure if i tested hdmi output ... mostly work with serial console and ssh <nckx>str1ngs: So for reasons I find questionable myself, you need to write ((#:tests? _ #f) #f). The 3rd element here is the default value if #:tests? isn't explicitly set, which gst-plugins-base doesn't do. If it's missing, #:tests? won't be substituted at all but will be silently missing from (package-arguments gst-plugins-base-next). <str1ngs>nckx: ah nice that is informative thanks. <str1ngs>nckx: does not help I work with goops inheritance all the time. so I need to translate this in my head. <nckx>Ah, sorry, I read ‘does not help’ wrong. <vagrantc>jsoo: haven't tested since linux-libre 5.4 or 5.5 or so ... hopefully 5.8 still works :) <pkill9>#:recursive? #t isn't working for local-file <str1ngs>nckx: ((#:tests? _ #f) #f) is working for me. also makes sense now thanks. <nckx>I wonder what the advantage (if any) of this silent behaviour is. I'd prefer explicit failure, even if it means adding more defaults to many packages (explicit is good). <nckx>I don't see how a ‘new’ user could have figured this out on their own... <guix-vits>nckx, jsoo, vagrantc: i just booted in linux-libre@5.8. Blank screen, need to see serial. (rockpro64, aarch64) <civodul>nckx: that's because it's called substitute-keyword-arguments, so initially it would only substitute, not add defaults <sneek>civodul, you have 1 message! <sneek>civodul, nckx says: Thanks, I noticed too late. The correct bug report should have landed by now 🙂 I also sent an e-mail to Mark about emacs y'day. I'm 50/50 on adding ‘please search the bug database before updating’ to the manual, but the contributing section is long already. Thoughts? <guix-vits>linux-libre-arm64-generic of the same 5.8 version boots with video output. <nckx>civodul: That historical perspective makes sense, thanks 😉 <civodul>nckx: re emacs, i think mistakes like this happen <civodul>dunno if it's worth making the guidelines even more verbose <civodul>but mhw mentioned not reading the list very often, which isn't great i guess <bandali>jackhill, re emacs-next, i only replied to guix-devel (before seeing your reply). if you like, please free to quote it while cc'ing the bug tracker <nckx>civodul: OK. BTW I don't blame mhw at all, I've definitely forgot to check the bug tracker myself before. Just an unfortunate package for this to happen to, that thread had a lot of work in it. <bandali>(disclaimer: i haven't really been following it) <nckx>I don't know if it's superior, but there are some differences that would be nice to compare. <pkill9>i wonder if there has been an attempt to sandbox commandline applications <pkill9>so when you run them on the commandline, they only have access to the files you specify in the command <nckx>Reversion wouldn't lead anywhere good. <pkill9>so you'd have the full benefit of sandboxing, without the inflexibility of profiles <bandali>i mean if it can be fixed quickly then yeah no need to revert <nckx>bandali: Some packages are broken with the new emacs. <bandali>nckx, right; and i thought that was the whole point of that bug report: to fix everything while landing 27.1 <str1ngs>pkill9: guix environment -C --ad-hoc bash coreutils -- bash does just that . it sandboxes in a container. <pkill9>str1ngs: i mean, sharing only the files in the container that will be modified/read by the program you use <pkill9>e.g. you'd run `ls <file>` and it would run ls in a container that only has access to <file> <str1ngs>pkill9: hard to do that dynamically though environment can do that too with --share and --expose <pkill9>maybe with some commandline scraping <str1ngs>not to bad if you want to just handle arguments though. but whats a command argument and what a file argument. so many edge cases. <nckx>It would be very hit & miss. Even assuming you whitelist parts of /proc & /dev, ‘ls -R’ still falls back to... everything? $PWD? ‘gzip file’ fails. You'd need a database. <nckx>You'd quickly find most cases are edge cases. <str1ngs>table only has on average four edges. and one if it is round :P <pkill9>local-file was working with #:recursive? #t afterall <pkill9>i don't suppose anyone can think of a way to create a magical package definition that updates a local repository and then uses that as the source, when the store requests it be built? <pkill9>specifically, i want to be able to get the latest version of youtube-dl from git whenever guix tries to build it <pkill9>have it update a local clone of youtube-dl basically <pkill9>that runs a command before building it <pkill9>for `guix build` and `guix package` commands <pkill9>kind of goes against the functional philosophy <pkill9>but there's nothing wrong with that <pkill9>maybe I could make a custom form of 'local-file' <pkill9>that runs git pull on the directory <guix-vits>top: guile-code to get both fresh repo and it's hash <guix-vits>middle: the (package: source=variable hash=variable <nly>X.509 certificate of 'ci.guix.gnu.org' could not be verified: <lfam>It works for me nly. In what context do you see that error? <lfam>Is this on Guix System, or another distro, nly? <lfam>Do you see anything when doing `env | grep SSL` <lfam>It should point to some directories and files in '/run/current-system/profile/etc/ssl/certs' <lfam>Does anything exist in that directory? <nly>Sat Aug 29 00:32:50 2020 <nly>sneek: later tell guix-vits Аркив <nly>sneek: can you tell me the release date of "guix tetris" command? <sneek>me, nly says: the release date of "guix tetris" command? <nly>sneek: later tell guix-vits lack of important userspace tools is a critical design flaw. <lfam>Can you either install openssl (or use `guix environment --ad-hoc openssl`) and then run this command and put the results on <https://paste.debian.net>? `echo | openssl s_client -connect ci.guix.gnu.org:443 | openssl x509 -noout -dates` <lfam>That will connect to ci.guix.gnu.org and give some diagnostics about TLS <sneek>guix-vits, you have 2 messages! <sneek>guix-vits, nly says: lack of important userspace tools is a critical design flaw. <nly>lfam: i think it did something, no error <lfam>I don't know nly... it should work. Without more details it will be hard to assist <lfam>Hopefully somebody else has some ideas <nly>lfam: there's another problem <nly>The following derivations would be built: <nly> /gnu/store/9b0waazb8w01990f0ha1fmngr3lhilps-ungoogled-chromium-84.0.4147.125-0.57244cd.drv <nly>i think this is a bug <nly>i think ungoogled-chromium should be built by default? <lfam>Yeah, ideally it would already be built <nckx>raghavgururajan: <Anything?> Building gnome-desktop without offloading is not an instant feat. Not sure why it's not substituting from bayfront. <str1ngs>nly: very close o getting webRTC working wih webkitgt. though it's very experimental <nckx>FFS, I was pulling from the old repo (disroot)... <nly>"very close to" I'm not sure who is close to getting webRTC working? <str1ngs>nly: I don't know how usable it will be. but at least the ground work will be laid for later down the road. <nckx>jonsger: IceDave's ‘update this together with IceCat’ comment seems to be consistently ignored. Is it obsolete? <nly>will you layoff the elves after the work is finished? str1ngs <str1ngs>nly: no, the elves have kids to feed. <nckx>The elves are turned into tasty botsnacks. <pkill9>where in guix's code does it copy the path pointed to by 'local-file'? <raghavgururajan>nckx: Ah, use to do clear cache command at least three times, each after download attempt. It might work on 2nd or 3rd attempt. <nckx>pkill9: local-file → interned-file → add-to-store. <nckx>raghavgururajan: Bizarre. You shouldn't have to clear the cache more than twice (and even that is a hack to work around ‘baking’). If the third is needed it was probably just for the time it added. <nckx>raghavgururajan: I did, but this is a different machine. <raghavgururajan>nckx: Could you retry`git pull`. Your local copy of the branch might not be up to date. <str1ngs>hello, I have a package that inherits cmake-build-system how can I change which compiler it uses? <nckx>Addi gcc-n to native-inputs. <hendursaga>What downloader does Guix use anyway? wget? curl? Does it resume interrupted downloads? <nckx>hendursaga: No. And it doesn't shell out to any external programme, wonder why that's such a common misconception. <nckx>It uses Guile's HTTP library to do its own downloading. <nckx>But glad that it looks convincing 😊 <hendursaga>I'll bet. Hmmm. Well, sad it doesn't resume downloads. Sometimes my connection is flaky :/ <str1ngs>nckx: do I need to delete exist gcc native-input. maybe it's not there at all? <nckx>Resuming downloads is not implemented but any mechanism that respects Guix's guixiness would be welcome. It just has to handle false starts/positives/&c. <nckx>str1ngs: Simply adding it should work. <str1ngs>I assume downloads are atomic, if it fails half way through it's destroyed? <nckx>Not sure if the name matters. <nckx>str1ngs: I don't know by heart if they're destroyed, but if not the previous file is removed, not re-used. <str1ngs>nckx: think the name is just a key used for the alist <nckx>Yes. But does the build system assoc-ref it by name? Best not to find out now. <str1ngs>I guess '("gcc" gcc-10) is not equal to '("gcc" . gcc-10) but car and cdr would still work. <str1ngs>so technically it's a list of pairs at least. <nckx>cdr would return something different in both cases. <nckx>It has to be a list of lists. *nckx has to go out, TTY'ALLL. <nckx>(Also: ("gcc" ,gcc "debug") -- try that in a pair-shaped world. o/ <jonsger>nckx: yes, somehow. If icecat is updated icedove should be updated as well because it inherit's icecat source <pkill9>i can't work out where to put a call to git to update cloned repository <jonsger>how can I debug a segmentation fault in guix copy? with gdb? something guilish? <joshuaBPMan>hey guixoids! I'm back to trying to get my client's site to use haunt. I built the site using pure guile, but now I suppose it's best to actually just generate static files. Since this site won't need to use a database. <pkill9>why am i overcomplicating this and not just using a script <joshuaBPMan>daemonspudguy: it can take a bit of time. I typicallly have to wait 3+ minutes to be able to log in <pkill9>joshuaBPMan: i want to have guix update a local git repository and then use that as the source for a package, specifically youtube-dl <pkill9>i just like the idea of guix doing it for me with normal commands like 'guix package' and 'guix build', only for those packages <pkill9>it's possible to do, but i can't work out <pkill9>but since i can't work out how, i'm just gonna use a script for my packages that use bleeding edge sources <pkill9>for now that is youtube-dl, and mpv using that youtube-dl <pkill9>since i have to guix pull for newer youtube-dl, and that's after it gets updated in the repositories, and youtube-dl hasn't had a release for a month for some reason <pkill9>now that i think about it, it's probably better to have aseparate script, because then you can have it generate the package version too, whihc oucl dbe useful for debugging <lispmacs[work]>Is there a trick, after installing a new emacs mode from Guix, to make that available without restarting emacs? <civodul>if there are still problems, let us know! <jonsger>civodul: thanks for the hint, I'm on eb622c6b128024179494253510bebe8bcacb8e6f from 27th August and still get those errors. guix show guix says guile-ssh@0.13.0-1.688d7f3 <jonsger>so the fix from this issue should already be in <jonsger>civodul: how did you created that core (dump)? <civodul>jonsger: "ulimit -c unlimited", then "guix copy ...", "gdb .../bin/guile core" <civodul>besides i'm updating guile-ssh to 0.13.1, which is probably almost the same as our snapshot <pkill9>i still want to make bleeding edge packages, lol <jonsger>civodul: there is no core file created <civodul>some distros have core files go to a special place <civodul>i think systemd can fiddle with that, too <jonsger>I had "kernel.core_pattern" . "/var/cores/core.%e.%p" before in sysctl-service but /var/cores was empty. I removed that service, reconfigured and rebooted <jonsger>all my systems running on Guix System, I don't have any foreign distros atm <jonsger>ah that sysctl thing is wrong as well as (pam-limits-entry "*" 'both 'core 'unlimited) doesn't set it to unlimited