***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | get Guix at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: http://logs.guix.gnu.org | 1.1.0 is out! https://guix.gnu.org/blog/2020/gnu-guix-1.1.0-released/'
***ChanServ sets mode: -o nckx
<nckx>mbakke: Thanks for your merge write-up. <mbakke>nckx: thanks -- I wish I had better terminology for the different types of merge conflicts :P <nckx>I did a little ‘wait, what?’ when you wrote ‘hidden merge conflicts’, it's good to be reminded I know nothing about this stuff. <nckx>I'm usually the git guru in the room (bizarre, I know). <nckx>Everyone's going to bed on these epic achievements. <nckx>And imma be all ‘welp, time for z's I guess’. <sirmacik>does anybody have an idea how to make hunspell-dict package more friendly for non english based languages? <sirmacik>I'd like to ad a Polish one but have no idea how to approach modyfing that package <roptat>sirmacik, I think we have French dictionaries too <sirmacik>oooh, I see them now. En dicts are at aspell.scm, others are moved to libreoffice.scm <roptat>probably because hunspell is defined in libreoffice.scm? <kmicu>I need to confess that every time Ludo mentions signalfd my brain replaces it and tells me that Ludo mentions Seinfeld. ***sneek_ is now known as sneek
<nckx>alextee[m]: Try loop-mounting it as -t hfsplus, if the Guix kernel supports that. <nckx>…but that's not in Guix… <nckx>🤷 Maybe unrar, maybe just waiting for that special alextee[m] to come along & bundle it up. <alextee[m]> /gnu/store/ywm5v7sbs5xfk3rhkngjrk9ddhxq13b3-p7zip-16.02/bin/7z <nckx>alextee[m]: ‘p7zip’? Any idea why? <nckx>Ah, the p stands for POSIX (I think). *alextee[m] has spent almost a week packaging zrythm for windows and has almost gone insane but thank god finally made a CI build it (on azure...) <nckx>7z is usually the first thing I install on other's non-free systems. I had no idea it was in Guix. Shameful. <alextee[m]>i tried mxe, cerbero, meson cross files... in the end i went back to mingw and ended up using a windows machine on azure with msys2.. i wish i could cross build on guix somehow if we had a framework for mingw packages.i doubt many people care (and that's probably a good thing), but as an app developer i think having lots of users on different platforms will lead to more stable software so cross platform is helpful (also i <nckx>alextee[m]: So is mingw in Guix only for wine? <nckx>Re: good thing: perhaps, but don't hesitate to propose mingw toolchain improvements or ask about how it's supposed to work on the mailing lists, by the way. Getting more free software on non-free platforms is FSF-fine. <alextee[m]>i'd help but i have no idea how the mingw toolchain works : - ) i can only complain <nckx>Please complain very constructively and it's all good. <nckx>(I don't know the first thing about wingthings.) <alextee[m]>i'll probably propose something that would be useful as a packager of things, and give an example of what i would expect from a mingw64 build system <nckx>alextee[m]: I assume you're in contact with dongcarl as well? <alextee[m]>he mentioned something about the bitcoin package here nckx: <alextee[m]>i looked at it but it's still a bit of wizardry to me *alextee[m] prepares some new patches <ryanprior>Guix has my 8-core machine pegged at 100% building ungoogled-chromium and it is ccrraawwlliinngg <sirmacik>afaik building chromium tends to kill any machine <ryanprior>Might have to abort my upgrade in 15 minutes if it doesn't pick up the pace, which would be sad. <ryanprior>It hasn't progressed 1% in the past 5 minutes which tells me this is going to be an hours long thing. <nckx>Good call. It's not going anywhere in 15 minutes on a mere 8 cores. <marusich>At least you aren't waiting on the daisy chain of rustc packages in order to build icecat <alextee[m]>should i add new packages at random places in .scm files? iirc someone mentioned that it's easier to merge that way without conflicts vs appending at the end <nckx>But those Rust builds are at least checkpoints of sorts. <marusich>IMO that's fine, alextee[m]. The packages are out of alphabetical order in many cases, anyway, and yes, adding them randomly is less likely to produce merge conflicts later. <nckx>alextee[m]: Eh, try to put them somewhere alphabetical instead, but most are such a mess… <nckx>‘Random’s a new one tho'. <alextee[m]>yeah there's no alphabetical order so i can't really do that <marusich>I personally am not sure there is much value in doing so <nckx>A more diplomatic no no. <marusich>If someone is looking for a package, usually they are not looking manually alphabetically; they are using git grep or guix edit <nckx>I don't like this new ‘random’ advice. Some files are (roughly) sorted. If anyone starts putting packages randomly in sorted files like perl.scm I will point at them until they stop. <nckx>It's an extremely noisy & destructive git change. <nckx>gnu: packages: Break ‘git blame’. <alextee[m]>well you can already search the git history for who did what changes to what package without git blame <marusich>It also increases the risk of merge conflicts when everybody decides to add their new packages at the end of the list. And because the order is not strictly enforced, it is likely that it will become unordered again. <marusich>I'm not saying you should always put something randomly in a list. I'm just saying that personally, I would not mind if packages are not strictly sorted. <marusich>I honestly would usually try to put things in an order of some kind that makes sense, but then yeah there is a small risk that merge conflicts can occur if it's a busy file. <nckx>alextee[m]: git log doesn't compete with git blame though. They are quite different. Or at least: I don't like git blame, but I still use it, so it must do something git log can't. <marusich>In the end, I think the downsides to re-ordering the list (encourages merge conflicts, makes git history harder to read, will not ensure order is maintained) outweigh the problems of leaving things kind of messy. <sirmacik>maybe ther should be some kind of commented out EOF mandatory snippet so those kind of patches don't cause much trouble? <marusich>Arguably, the lack of visibility into git history is something that git porcelains should be able to make go away. <nckx>If you're starting a new file by all means sort the things (and add a comment asking others to do so, perl.scm-style) but don't submit mass reshufflings. <marusich>And, we could have scripts that enforce the ordering of packages etc. But I don't think we do. <marusich>sirmacik, the problem with merge conflicts isn't that the changes happen at the end of the file - it's that they modify the same portion of the file. <alextee[m]>we almost have as many lv2 plugins as archlinux! ***catonano_ is now known as catonano
<azvede>is there a guix package that contains the ldd command? `guix search ldd` gives me nadanothing <azvede>is there a discoverability method I can use that would be better than guix search 'command' and less annoying than troubling you fine folks? <anadon>nckx: I'm still going over your response email this weekend. It'll take some time to get together a strong argument, but I think it is there :P <nckx>Here my lack of IRC ←→ mail name mapping fails me. <nckx>Welp, time for z's I guess. o/ <pkill9>does anyone know how to fix this error when running `ssh -X <ip>`? Warning: untrusted X11 forwarding setup failed: xauth key data not generated <pkill9>into a server running guix system <pkill9>i've enabled x11 forwarding in the openssh server, and confirmed it by reading the config file the process is using <anadon>nckx: the client daemon implementation and interfacing <anadon>nckx: Usually that's me that can't keep the names straight :P <anadon>pkill9: If you _really_ trust the address, try "-Y" instead. <azvede>so, any suggested method for determining which package contains a command you want? <pkill9>anadon: i tried that too but it didn't work <pkill9>with -Y it says "Warning: No xauth data; using fake authentication data for X11 forwarding. <pkill9>i added stuff to ~/.ssh/config on the remote machine too <anadon>pkill9: In an isolated environment -- one which has forgotten the previous sert for that server -- try using ssh -X there <anadon>Looks like the Aegis package no longer compiles, and is no longer maintained. Author looks like he fell of the face of the earth in 2014. <anadon>pkill9: I don't remember that bit off hand. I'd try googgle for removing an ssh cert. <anadon>Holy crap, the maintenance group is all together dead. <anadon>Under what conditions do re remove packages? <azvede>presumably the maintenance group of the Aegis package <pkill9>i like abandoned stuff, like abandoned buildings <anadon>Aegis was a version control system. <anadon>Looks like John Darrington and Alex Kost are the originators of the package. Are they still around? <anadon>Original submiters seems to be quiet, too. John hasn't been on in 2020. <vagrantcish>guix doesn't have a strong maintainership model, though ... e.g. anybody can propose to update any package, in general <apteryx>indeed. That the orignal contributors of a package are not around anymore or haven't bothered maintaining said package doesn't mean that much in Guix. It's up to anyone who has an interest in said package to maintain it. <azvede>am I missing a distinction between project maintainer and package maintainer? because that seems like it could be problematic if anyone can make a change to a package <anadon>I'd feel bad updating the version and updating the homepage but still knowing the thing can't build. <azvede>anadon, seems like if it can't build, updating is a fine thing <vagrantcish>azvede: anyone can propose patches, some people can commit directly (though are encouraged to propose patches for significant changes) <azvede>vagrantcish, ahhh, that puts my mind at ease <anadon>I don't envy the user who will need this. Best advice to them is to go back in history and build the thing from an older state of guix right after the first few commits. <apteryx>anadon: updating the version and homepage doesn't make much sense if the package doesn't build; perhaps a fork exists that fixed the build problems, or some patching could be done to make it build <anadon>apteryx: It is abandonware. I don't think any exist. <anadon>Confirmed that aegis's author died in 2015. <anadon>Rest in peace Peter Miller. Your name has echoed yet again. <anadon>Is it possible to specify a build system from guix at a certain point in time? <apteryx>no. You have to start with a given build system, and add phases of another build system to combine more than one build system. <butterypancake>I'm having trouble package opendoas. It's configure script doesn't support setting variables as arguments (ex ./configure CONFIG_SHELL=/blah/blah). I'm not sure how I'm supposed to remove this type of argument from the configure-flags <pkill9>what could cause 'undefined reference' errors in the linking phase of a binary in a compilation in a guix build, but not when manually compiling? <anadon>OK, aegis got fixed up. Patch submitted. Hope Markus doesn't grill me this time! <apteryx>pkill9: a missing library (the obvious one :-)). Or a missing environment variable? LIBRARY_PATH is the one, I believe. <pkill9>It's from a library file in the source though <anadon>Yeah. On the face of it, it is sad. I'm in no place to judge the man. <anadon>Wow. He had an impact. I was using gettext last week. <anadon>This is why we need the internet archive. <pkill9>yea, loads of packages use gettext ***sneek_ is now known as sneek
<marusich>sneek, later tell dftxbs3e I haven't finished reorganizing/reformatting all your commits yet, and I have some questions I will ask later, but for now I thought you might want to know that with your first small change, applied to origin/master, a cross-built guile does not segfault: https://paste.debian.net/1149069/ <raghavgururajan>I need an urgent help with git. Anyone proficient with git is online and available for 10-15min please? <azvede>hi again guix, so I found that online man pages can be the reference from command to package I was looking for... but now I'm running into a situation where a perl install script cannot find commands that I know exist... uname and cut... is this a profile issue or something where I can use coreutils, but my perlscript can't? <azvede>script gives me `sh: uname: command not found` whether I sudo or not; uname returns `Linux` <azvede>rekado_ ah, that gives me an avenue to run down <azvede>let me check into that, thanks and sorry for missing the obvious <raghavgururajan>So I cloned guix repo and `cd guix`. Then did `git worktree add --track -b wip-desktop ./wip-desktop origin/wip-desktop`. <raghavgururajan>When I `cd wip-desktop` and did `git status`, I get Your branch is up to date with 'origin/master'. <rekado_>can you do “git checkout wip-desktop” in that worktree? <raghavgururajan>You mean to do `git checkout wip-desktop` inside '~/guix/wip-desktop'? <rekado_>your worktrees are *sub-directories* of the main repository? <rekado_>can you try adding a worktree in a sibling directory instead? <rekado_>my worktree setup looks like this: ~/dev/guix/branches/{master,core-updates,…} <raghavgururajan>So to do `git worktree add --track -b wip-desktop ./branches/wip-desktop origin/wip-desktop` in the '~/guix'? <rekado_>the master branch is in ~/guix, isn’t it? <rekado_>I don’t think you can put worktrees inside of repo checkouts <rekado_>I would clone to ~/guix/branches/master <rekado_>and then add the worktree for wip-desktop to ~/guix/branches/wip-desktop <rekado_>~/guix should not be a repository itself <raghavgururajan>So `git worktree add --track -b wip-desktop ../wip-desktop origin/wip-desktop` instead? This will create worktree as ~/wip-desktop, alongside ~/guix. <raghavgururajan>Okay. Just a thought. Instead of worktrees, can I clone different branches directly via `git clone`? <rekado_>yes, you can do that but you will have multiple copies of the repository then <rekado_>with worktrees you share the one repository but get separate views on it <azvede>rekado_ seems like it's not interacting with the path as far as I can tell... is it like MS where there's a different path for different contexts? <rekado_>this also means that for worktrees you don’t have to run “git fetch origin” separately; once is enough <rekado_>azvede: no, there’s just one PATH variable that will be effective <azvede>sh: uname: command not found; sh: cut: command not found being thrown by the perl script.... huh... <rekado_>azvede: how does it spawn uname? Have you grepped the source code? <raghavgururajan>Now, I wanted to checkout multiple temp branches based-off wip-desktop. So I would normally do `git checkout -B fix-foo` inside ~/wip-desktop, correct? <rekado_>yes, but that might be confusing given the name of the worktree <rekado_>you can do that, but you would still need to switch branches and recompile stuff after switching <rekado_>worktrees are rather cheap, so maybe just add more worktrees? <raghavgururajan>Hmm. My plan is to have a local branch 'wip-desktop' that tracks origin/wip-desktop. Then create temp branch based-off on local wip-desktop and create patches against it. These patch will be sent to Danny, which will be reviewed and pushed to origin/wip-desktop, by him. <raghavgururajan>So if I have multiple worktress, is it possible to format patches against another worktree? <rekado_>yes, your other worktrees can be based on wip-desktop <rekado_>whenever you update wip-desktop you should rebase them <azvede>yeah...rekado_ it calls uname by doing my $release = `uname -r | cut -f1 -d-`; <azvede>which seems like it should just work <rekado_>azvede: can you print the value of the PATH variable in that script? <azvede>i'll stick a debug print line in there, yeah <rekado_>raghavgururajan: but you only need to bootstrap and configure once <rekado_>and you’ll only have to repeatedly make those files that you changed in the worktree, not all files that differ after switching branches <raghavgururajan>Oh, I was hoping to prevent that. Because I get "this is different from that" prompts everytime I change working dir. This consumes too much starting time when I try to build something. <rekado_>raghavgururajan: but it’ll be worse when switching branches in the same worktree <rekado_>huh, I don’t know how this is possible, but my COLUMNS variable is reset <rekado_>I started a root shell and typed “export COLUMNS=1024” <rekado_>then in that shell session I started the daemon <efraim>I have 3 worktrees, master staging and core-updates. My wip-ppc branch is against core-updates so I check it out on my core-updates branch, rebase, switch back and run make again <raghavgururajan>Ah!. Okay, if I want to create another worktree 'fix-foo' based on the worktree 'wip-desktop', what should be the syntax? <rekado_>then I ran “guix build foo” in another session <rekado_>and back in the root shell COLUMNS is now 146 <efraim>if it were me I'd just use a branch instead of a whole worktree and only check it out on the wip-desktop worktree path <rekado_>yeah, if it is short-lived and only one file will change then a worktree is too much work <raghavgururajan>`git worktree add -b fix-foo ../fix-foo` while being in ~/wip-desktop? <efraim>that looks right, but I'd have to check the documentation again <efraim>sometimes after I git-pull in the morning I'll open a new terminal window, cd to guix and run 'guix environment guix -- make && exit' and minimize it. no need to wait for it to recompile the modules to keep working <rekado_>hmm, changing the zoom level of my Emacs window changes COLUMNS <azvede>after much futzing with getting perl to print a global variable in a sub, I have confirmed that it does have my normal path <efraim>if I'm choosing a specific commit for a channel I use 'commit' or 'branch'? <raghav-gururajan>ld: libstore.a(libstore_a-build.o)(.text+0x2000000f918): reloc against `_ZN3nix8SysErrorD1Ev': error 4 <efraim>making guix-daemon should be single-threaded <efraim>I'd run make, C-c after the daemon and then make -j3 or whatever number <efraim>depending on how much you want to avoid 'make clean' I'd start by removing the .a files in the guix checkout and see if that takes care of it first ***apteryx_ is now known as apteryx
<mothacehe>I'll send an email regarding the second half of "WIP directives" later on. <janneke>it looks like your idea to create an explosive mixture of our disk-image and hurd-vm patches has worked! <janneke>;) good; i have pushed the <menu-entry> rewrite to my gitlab, together with cleanups and other smallish rewrites <janneke>i didn't want to reset savannah just yet and start that review -- better do your work first, wdyt? <janneke>mothacehe: there's one ugly directives-related diff on 'wip-hurd-vm-new' that procudes a working disk image <mothacehe>yes savannah is in a "working" state, so maybe we can keep it that way until "WIP directives" is handled <xelxebar_>I think there might be a (minor) bug in the code that checks for and displays mismatched hashes. When first coding up a package, I fill the base32 hash with a bunch of "x"s but when attempting a first build it claims the expected hash is "1xxxx..." <civodul>(bytevector->base32-string (base32 "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx")) gives an interesting result <civodul>"xx35467pxx35467pxx35467pxx35467pxx35467pxx35467pxx3q" <civodul>ah but (bytevector->nix-base32-string (base32 "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx")) gives "1xxx..." <civodul>i guess the 5 least significant bits are ignored or something like that <PurpleSym>Somehow UID resolution is not working in `guix environment -C` for me. The shell just says "I have no name!". I tried modifying /etc/nsswitch.conf to include “files”, but no luck. Any ideas? <civodul>PurpleSym: "I have no name!" is for the host name <PurpleSym>civodul: No, it’s definitely the username: I have no name!@node01 ~ [env]$ <civodul>normally in -C there's only /etc/{group,passwd} in the container <PurpleSym>nsswitch.conf from the host, as well as resolv.conf and services. <civodul>this is on a "foreign distro", right? <civodul>so it may be that /etc/nsswitch.conf requires NSS extensions not available in the container <civodul>do you have /var/run/nscd in the container? <PurpleSym>NSCD is running, I also see a socket in /var/run/nscd, but it’s running *outside* the container. <civodul>it's ok that it's running outside, that's the whole point <civodul>could you add strace to the container and run "strace -o log id" and paste it? <janneke>civodul: thanks for your reviews, just chiming in real quick here <janneke>on wip-hurd-vm, we succeeded in kludging our way around running a native qemu and fixing cross-build issues to finally produce a working guix system vm-image <PurpleSym>I think I already know what’s going on: NSCD is running outside the container, but there is no UID 1000 outside. Since processes inside the container will use that nscd to resolve their UIDs, it’ll fail. <janneke>it has some rough edges (e.g., weird hurd-exceptions, the sqlite thingy)...but it works <janneke>now, we also *almost* have disk-image working, so we could try to remove all workarounds for qemu-image (sqlite) and jump onto disk-image right away <janneke>civodul: i thought that we were somewhat "done" wrt the qemu-image cross build (hence: merge wip-hurd-vm)...but if that turns out to be much work...eh help! :-) <PurpleSym>If I --expose=/empty=/var/run/nscd it works as expected, so nscd is definitely the problem here. <civodul>janneke: yeah i don't know, maybe i'm trying to catch up but there's so much going on! <civodul>looks like there are several discussions and patches in parallel <civodul>like mothacehe said we could bypass (gnu system vm) entirely, so i don't know if it's still relevant to comment on these changes <janneke>civodul: np...;) i have pushed the <menu-entry> rewrite to my gitlab (wip-hurd-vm), together with cleanups and other smallish rewrites <janneke>that needs one extra patch to actually produce working disk-images (a very hacky commit lives on wip-hurd-vm-new), and mothacehe is working on doing that properly <janneke>then we want to reset wip-hurd-vm on savannah, mothacehe is also looking into my new <menu-entry> patches <janneke>so..yeah, it's kinda explosive...which has good and bad aspects :-) <mothacehe>hey civodul. janneke, do you think we want to merge the vm-image related stuff? <janneke>yesterday i thought vm-image/qemu-image was working and "done" / OK to merge so i was in favour of merging and then deleting <janneke>now it seems that it would need some work (see register-closures/sqlite, maybe more) ...so it could make sense to drop it? <civodul>on master "./pre-inst-env guix system vm --target=arm-linux-gnueabihf gnu/system/examples/bare-bones.tmpl -n --no-grafts" doesn't work <civodul>because of the bag-graft issue probably <mothacehe>janneke: yes that's what I think, as closure registration should work with disk-image (and the sqlite issue does not exist). <civodul>so it's really hard to just know where we are <civodul>i think the sqlite issue is a symptom, not the root cause <sirmacik>something about yesterdays server works? <janneke>civodul: wrt sqlite, i imagined that doing it properly was a waste, as disk-image already does it properly <mothacehe>civodul: yes the master issue seems to be related to the grafts problem <janneke>and that it's so sad that when you're happy not to register closures (we've been doing #:register-closures #f anyway until now for the Hurd), and thus do not use sqlite, the build still fails because the module gets pulled in <janneke>so, i opted for a quick and easy hack to use until it's removed... <civodul>i'm always afraid of having to support quick-and-easy hacks for the years to come :-) <civodul>dynamic binding was a quick-and-easy hack from 2013 and it makes us suffer every now and then ;-) <mothacehe>janneke, civodul: we could maybe turn wip-hurd-vm into wip-hurd-disk, which would drop any VM related stuff? ***dingenskirchen1 is now known as dingenskirchen
<janneke>mothacehe: yes! i was just about to propose doing that in-place, but wip-hurd-disk is also a great idea <mothacehe>janneke: good! Your new <menu-entry> approach is terrific ;) <janneke>mothacehe: great! well, dropping VM related patches makes the review easier anyway and code base smaller <janneke>i'm going to take a stab at that -- it's still tempting to just reset wip-hurd-vm, dunno -- let me hear what you'd like, civodul/mothacehe <rekado_>the problem is actually an undiagnosed error in guile-xapian, which crashes the application… <rekado_>wd-1: are you not using the Guix package for it? <rekado_>I found that much more convenient than compiling it manually <wd-1>i don't really want to mix straight-use-package and guix's emacs packages, especially since emacs-guix appears to be broken, and has been for me for most of this year. <wd-1>i also don't compile much, but the problems here seem to hint at broader issues than just an emacs package <sirmacik>rekado_: thanks, as for the error... uh, that sucks, but whatever works. <efraim>well, I think ly works. hard to say <janneke>mothacehe: /me pushes a new wip-hurd-disk to gitlab <janneke>which uses your HURD nodes and adds two hacky commits <janneke>mothacehe: i hope you don't mind my patches bringing "back" old kludges -- i'm trying to take small steps while keeping stuff working <janneke>and hope it helps you in doing a proper rewrite <mothacehe>janneke: not at all, it's starting to get in shape :) *janneke has been trying to build that all morning...my offload build keeps hanging and then fails, just now my ssh connection got interrupted :/ *civodul tries this on master: ./pre-inst-env guix system vm-image --target=arm-linux-gnueabihf gnu/system/examples/bare-bones.tmpl --no-grafts <civodul>the good thing, if we fix that, is that we're closer to a good state <mothacehe>janneke: could you update your wip-hurd-disk branch from git@gitlab.com:mothacehe/guix.git ? <janneke>mothacehe: ah, great => + (file-system-options '("-o" "hurd" "-O" "ext_attr")) <janneke>that removed the need for the fs-options hack *civodul wonders whether nckx's place changed timezones <nckx>rekado_, raghav-gururajan: Worktrees are just (fake) git repositories with their own .git, you can nest them just fine. I suggested ~/guix/.worktree/foo because that's what I use but use whatever works for you raghav-gururajan. <nckx>civodul: I am a citizen of the world! Time is an illusion! Also it's 13:40 here. <nckx>anadon: Should have logged in here before calling aegis ‘dead’. Inappropes. Thank you for taking care of it. <rekado_>I would have liked more information on how emacs-guix is broken <rekado_>I don’t like comments that imply things have been broken since forever, and then there’s never enough actionable information to confirm that or fix it in the best case. <rekado_>so: o people of this channel! Here is my plea to you: please report bugs to bug-guix@gnu.org and don’t work around problems. They fester. <raghavgururajan>Is it necessary to propagate all packages mentioned in 'requires' field of .pc file? <mbakke>civodul: the tunnels to nckx's aarch64 machines on berlin are down <raghavgururajan>nckx: Is it necessary to propagate all packages mentioned in 'requires/requires.private' fields of .pc file? <mbakke>raghavgururajan: yes, they should be propagated so that e.g. 'pkg-config --libs foo' works if you run 'guix environment --ad-hoc foo pkg-config' <nckx>raghavgururajan: Sorry, I'm going to be ‘here’ but AFK most of the time today. <mbakke>raghavgururajan: do you have an example? sounds like the linter is overzealous if that is the case <mbakke>or, which package is the linter suggesting to move to native-inputs? <rekado_>mbakke: I hope they are no longer necessary. Have you tried connecting directly? <mbakke>raghavgururajan: oh, hm... that probably should not be propagated, sounds like a bug in the .pc file <mbakke>rekado_: I can connect from home, but not on berlin *janneke remembers a git pull --roll-back ... ah --allow-downgrades --roll-back <civodul>mothacehe: how does one boot a VM with qemu-system-arm? <civodul>qemu consumes CPU but there's no console <mothacehe>civodul: I never tried to run a "final" system with qemu-system-arm. *janneke reverts to cd5d5f53228fd5bf96d9f790aa2606ae71fa68d7 to get a working qemu <mothacehe>But producing a disk image for ARM, involved spawning a qemu-system-arm. So at some point in time it did work. <janneke>i finally have an error: make: *** [/tmp/guix-build-qemu-5.0.0.drv-0/qemu-5.0.0/tests/Makefile.include:636: check-qtest-x86_64] Error 1 <mothacehe>civodul: The Qemu command line to boot an arm system is tricky. You need to pass "-M virt", check that your console is "ttyAMA0" at least. <mothacehe>You can check for those flags in "load-in-linux-vm" procedure of (gnu build vm). <civodul>based on a variant of janneke's patch, i can do "vm-image --target=arm-linux-gnueabihf" <civodul>now i need to check that it's a valid image <mothacehe>nice! for now, I consider that a cross-built image offering a prompt is a valid image :p <butterypancake>so I'm packaging a c application using the gnu-build-system, and for some reason, I have to specify "CC=gcc" even though the makefile has "CC ?= gcc". If I don't it tries to use "cc" which doesn't exist. Is specifying "CC=gcc" correct or do we support other compilers as well? <butterypancake>maybe I should mention there is no configure script so I had to skip that phase <nckx>butterypancake: Not transparently. Passing ‘gcc’ is fine but take a look at commit aa784dc for how to do so with cross-compilation in mind. ***danielalura is now known as danjelalura
<nckx>alextee[m]: That a familiar error by any chance? <alextee[m]>if it's not fixed upstream yet it's easy to patch <nckx>Oh, there's a 1.7.1 release. <nckx>oshimiLV2Plugin.cpp:837:1: error: invalid conversion from ‘void* (*)(const _LV2UI_Descriptor*, const char*, const char*, LV2UI_Write_Function, <lots of ints> <nckx>Different but same same. <butterypancake>so it looks like I'm using an autogenerated github tarball. What's my alternative? Hard code the commit of the version? <nckx>butterypancake: (commit …) can be anything that identifies a git object. No tags? <nckx>(commit version) or (commit (string-append "v" version)) are common. <nckx>I meant that commit doesn't have to be a raw 40-character commit. It can be anything that git knows about, like a tag or (don't do this) a branch. <nckx>You'd use (commit (string-append "v" version)) to make updates fun. <butterypancake>Ok, so I've sorted out all the lint warnings except this one: ./mspdebug.scm:16:11: mspdebug@0.25: scheduled Software Heritage archival <nckx>Heh, that's not a warning. <butterypancake>I'm glad it's displayed exactly the same as all the things I had to fix then :/ <butterypancake>anyway, I made a package! I'm excited! Time to submit, however I do that! <nckx>butterypancake: No, I agree, it's not like the other warnings and (IMO) shouldn't be shown like that. <apteryx>butterypancake: yay! :-) Submitting patches is covered in info "(guix) Submitting Patches". The whole Contributing section is a nice read, too. <nckx>alextee[m]: Didn't mean to make it your problem, you're just the LV2 person in my mind now. <nckx>butterypancake: Congratulations by the way 🙂 Submitting is the easy part, it only gets tricky with multiple patches. I recommend setting up git send-email (guix install git:send-email), once that's over & done with you'll save time & always send good patches. Saving others time. <alextee[m]>nckx: any LV2 problems are my problems too! LV2 must prevail ⚔︎ <nixfreak>whats the command to see multiple profiles and their generations? <apteryx>'guix package -l' lists the generation of your user profile <apteryx>there's also a 'guix package --list-profiles' <apteryx>and the 'guix package' can take a -p option to specify a profile <apteryx>so, you could do something like this at the shell: for p in $(guix package --list-profiles); do guix package -p "$p" -l; done <nixfreak>very cool I see for loops a lot for work <butterypancake>so I'm reading through the contributing info page but maybe it isn't up to date? apparently the guix makefile doesn't have an 'authenticate' target for me? <rekado_>butterypancake: ’make authenticate’ only works after bootstrap and configure <rekado_>butterypancake: arguably it’s mentioned too early in the manual <nckx>Depending on your set-up you might have to run it as ‘guix environment guix -- make authenticate’ too. <nckx>A note pointing back to bootstrapping would be nice. <nckx>butterypancake: #goodfirstbug 😉 <civodul>mothacehe: "console=ttyAMA0" + "-M virt -serial stdio" doesn't help <alextee[m]>nckx: yoshimi bug looks fixed in master, but not released yet <civodul>oh i was just reminded of libguestfs, maybe something we could use in the new image API <nckx>alextee[m]: Cool. I'll add it as a patch. <nckx>Yeah, something like that. <nckx>I think 1.7.1 is fine here. <mothacehe>civodul: you also need to pass -kernel and -initrd I guess <mothacehe>one trick could be to use almost the same command line as the one used in load-in-linux-vm, but changing the device to the one you just produced. <civodul>mothacehe: i wanted to run an image returned by "system vm-image" <mothacehe>civodul: yes I get that. You picked the bare-bones.scm configuration, hence Grub bootloader. I doubt Grub supports ARMv7. <mothacehe>So you need to specify kernel/initrd by hand <civodul>our cross-compiled Guile 3.x is crashy with JIT enabled :-) <civodul>so it crashes in /init, in the initrd <mothacehe>oh, ok. We could also provide a configuration with a bootloader supported by qemu-system-arm, so that the vm-image is directly bootable. For now, I only worked with specific target (hence specific bootloaders). <reepca`>are signal handlers inherited by new threads? <nckx>guix-vits: Sounds like a relevant daemon question. <nckx>Have faith in our only person brave enough to hack the daemon. <roptat>change @var{system} with x86_64-linux so it would work in most cases, and propose changing that with i686-linux for the other architecture <roptat>the second would be: add a QR-code to the manual when we tell users to reboot (and mention the availability of the manual). I've found that on the tails manual, and I think it's a great idea. What do people think? <roptat>(the QR-code would help people with a smartphone to open the manual on their device) <nckx>roptat: @var{system}: Fine. What does a QR code do? <roptat>it's a simple image that you can scan from your smartphone. it would contain the URL of the page you're seeing, so you can easily open it on your smartphone <NieDzejkob>(it can encode any bytestring in general, but it's common to put URLs in them) <nckx>Thanks for enlightening a blissful luddite. I'd seen it on a systemd system long ago (and on posters, of course). <dissoc>what is the proper way to deal with non-guix bash scripts. most reference /bin/bash. is the expectation to replace them? <nckx>dissoc: Depends on the context. If you're building a package that uses them most are replaced for you by the build system, and you need to replace corner cases yourself. <apteryx>dissoc: you could change them to use #!/usr/bin/env bash <nckx>On ‘real’ systems, /bin/bash and /bin/sh have been de facto deprecated for decades, so change the script to use /usr/bin/env which will work out of the box. <roptat>would it? I thought we didn't install /usr/bin/env by default? <dissoc>nckx: that makes sense because i've experience that from writing packages. <nckx>roptat: Oh, possible, it's changed more than once. <nckx>It's probably still in the manual then, just search for /usr/bin/env. <roptat>oh I have it on my system and it's not on purpose <nckx>I have it on mine and it is. <dissoc>thanks for the answers. my case is pretty greasy. it involves some build scripts for a java app that uses native code, which has some bash scripts <apteryx>nckx: are you sure the practice of using #!/bin/bash is deprecated? I see it quite often still. <nckx>roptat: I don't think it's great to have it, but we got a question literally every week and I was sick of it. <nckx>apteryx: There's no authority. <apteryx>to me its whether you want to use the system bash vs any version of bash that happens to be in the PATH. Depending of the context both could be correct. <nckx>‘It breaks a lot, guess what people will say what you tell them’ is a close as it gets. <nckx>apteryx: That's not up to the script author. Writing scripts on your own system, of course you do what you want, but then you know what to use. <nckx>I use /run/current-system a lot. <apteryx>especially in embedded circles, where everything is custom made for a single application and hard referring to things is not really frowned upon <nckx>Right, that's different. <nckx>Of course the real portable solution is curl | sudo bash. <apteryx>nckx: why isn't it great to have #!/usr/bin/env? <nckx>Blah blah purity blah blah. It was just my throwaway persopinion. *nckx pretending to work so needs to type something sometimes. <nckx>If any future employer reads that (a) hi! hire me (b) don't hire me to respond to e-mails when you don't actually get any e-mails and then blame me that I'm not doing anything. <apteryx>I think you also made the point that if we have /bin/sh, we might as well have /bin/bash in the paste <nckx>Oh, really? Possible. I'm sure I had great and mad intelligent arguments, but that whole deal didn't end too well and I'm loath to relive it. <rekado_>mv /run/current-system/profile/bin /bin <reepca`>something something read-only file system? <nixfreak>guix package -i enlightenment --upgrade , correct or no <nixfreak>or does that just re-install the package <reepca`>nixfreak: depends on what you want to do. That command will create a new generation of your user profile containing enlightenment and updated versions of all packages from the current generation of your user profile. <apteryx>nckx: enjoy AFK; IIRC the argument for /usr/bin/env (and to a lesser degree /bin/bash) was that we already had /bin/sh, and that if the purity argument was to prevent it should be removed for consistency. <roptat>nixfreak, if you only want to update enlightenment and keep everything else at its current version, "guix install enlightenment" will do that <apteryx>dissoc: there's also the extra-special-file service that you can use to create any symlink in a declarative fashion <mbakke>the git dependency should be removed though <janneke>so...what's the right curse to get a minimal texinfo doc setup? i''m trying texlive-bin texlive-tex-plain texlive-tex-texinfo <janneke>but then i get: TeX neither supports -recorder nor outputs \openout lines in its log file <apteryx>janneke: I would have though intalling texinfo should be enough? does it not refer to TeX absolutely? <rekado_>janneke: always include texlive-base <rekado_>I’m not sure it’ll fix things for you but it’s the set of packages that you need when you want to do anything with LaTeX <rekado_>(it’s the “required set of LaTeX packages”) <janneke>i needed also epfs; so this works for me: texlive-bin texlive-base texlive-tex-plain texlive-tex-texinfo texlive-epsf <TZander>heya, does anyone know of a simple way to make this line go away? hint: Consider setting the necessary environment variables by running: [GUIX_PROFILE= etc] <TZander>and, naturally, the GUIX_PROFILE env var is set (to /var/guix/profiles/per-user/). <roptat>I have written a guile library and some of the tests require network access, so I can't run them in a guix build environment. Is there a way to disable only these tests, instead of every tests? <NieDzejkob>the next line, where it tells you to source the profile file, is the important one <NieDzejkob>TZander: is this Guix System, or a foreign distro? <alextee[m]>did you replace this line? YoshimiLV2Plugin.cpp:87 <nckx>alextee[m]: Because last release + patch is preferable. I haven't tried building master yet. I didn't change anything, just applied the attached patch. <TZander>NieDzejkob: foreign. It was printed just after doing an upgrade. *nckx will build master next. <alextee[m]>all instances of "struct _LV2_Descriptor" should become "LV2_Descriptor", and all remaining instances of "_LV2_Descriptor" should become "LV2_Descriptor", you can just use sed i think <TZander>NieDzejkob: oh, and on login the 'source' of profile is run. So not sure why there is this hint <NieDzejkob>TZander: this usually happens when the profile file got some new env vars added to it <NieDzejkob>restarting the shell will load them and make any new programs (or programs that now handle their environment variables differently) fully work <NieDzejkob>for example, we somewhat recently merged the core-updates branch, which means that GCC now uses C_INCLUDE_PATH and CPLUS_INCLUDE_PATH instead of CPATH <TZander>ohh, I guess that makes sense. The message is very confusing, though :) <roptat>oh also the tests use scheme modules, and I'd like to make them with tests, but I don't understand where to put them in my Makefile.am <nckx>alextee[m]: There is a misunderstanding: there *are* no occurences of either to replace. But building master works, I'll just use that. Thanks. <nckx>Yep, this was far less effort than just commenting out yoshimi to update my profile 😊 *nckx celebrates with a shitty tune ♪ <dftxbs3e>nckx, rekado_, hey! did the 10G ethernet end up being fixed? :D <sneek>Welcome back dftxbs3e, you have 1 message! <sneek>dftxbs3e, marusich says: I haven't finished reorganizing/reformatting all your commits yet, and I have some questions I will ask later, but for now I thought you might want to know that with your first small change, applied to origin/master, a cross-built guile does not segfault: https://paste.debian.net/1149069/ <rekado_>roptat: what does “make them with tests” mean? <roptat>I'd like these modules to be built only when I run "make check" <roptat>currently I've put them in SOURCES, but at install it installs the test modules which are not part of my library <rekado_>roptat: you can skip tests by overriding TESTS, e.g. make check TESTS=this <rekado_>roptat: you shouldn’t add them to SOURCES <roptat>but I still need to build them, right? <roptat>I mean, I have tests/online.scm which uses modules in test-modules/ <roptat>but test-modules/... are not test programs themselves <nckx>dftxbs3e: Not yet, IIUC fixing that will require migrating ‘berlin’ to another machine first. <rekado_>and to run them we define SCM_LOG_DRIVER <rekado_>dftxbs3e: I suspect that the NIC is broken. <rekado_>we don’t have a spare that would fit in that server, but we have other servers with 10G NICs <roptat>so test-modules/testsuite.scm does not belong to my library, but it's not a test file, it doesn't belong to TESTS either <rekado_>(why does the readme say: “Otherwise, your package manager might have guile-jsonld available”?) <roptat>probably because I copied it from my guile-jsonld library :p <dftxbs3e>sneek later tell marusich I used GNU Guile 2.2 previously for some reason <emys>hi, can a package have conditional dependencies (inputs) depending on a choice of outputs? <roptat>emys, inputs are fixed by package, but you can create variants with more or less inputs *apteryx fixes ABI mismatch errors with: grep --include='*.scm' -rl origin | sed s/scm/go/ | xargs rm -f {}\; <apteryx>crude, but more efficient than 'make clean-go' ;-) <TZander>it would be nice if guix could build out-of-tree (which includes not changing any source files due to translations). <nckx>emys: Outputs aren't conditional and are all built together, so there's no way (or -where) to split inputs. Could you give a concrete example? <emys>nckx, so let me explain what I want to do. I want to us hg-git, the mercurial extension that lets one clone git repos with local checkout being a mercurial checkout. <emys>thats the hg-git package I came up with <emys>turns out, the extension is not found by mercurial <emys>I think it is because hg-git is not an input of mercurial <emys>so hg-git is not in the paths <emys>to fix it, hg-git would need to be an input of mercurial <emys>arguably I think it wouldn't be a huge price to pay to add it as an input to mercurial for everyone <emys>yet, having it optional would also be nice so I wanted to explore the options in that regard. <nckx>Yes, that would make it a hard dependency. What we do instead is make packages look in a known plug-in directory (or even more ideally: list of directories). <nckx>Completely fictional example: MERCURIAL_EXTENSION_PATH=/gnu/store/foo:/gnu/store/bar <nckx>Does mercurial support anything like that? <emys>so I am not a mercurial expert, what I saw is that in the .hgrc file one can give paths to extension <emys>like for each extension a specific path <nckx>Hm, that's not great, Guix can't set that for you. <emys>which is kind of impractical with guix because each update will change that path <emys>I guess (kind of new to guix) <emys>will look into the hg docs <emys>guix size python-hg-git. ..... # => total: 0.2 MiB <nckx>emys: It's likely that /gnu/store file names would end up in the configuration and break later, yes. It's happened many times before. <nckx>I have to leave now but I'll read the log later and will look into hg extensions a tiny bit. <butterypancake>Submitted my first patch! This is the biggest open source thing I've done to date! How long until it shows up in debbugs? I'm a little nervous :P <MSavoritias>Hi. I bought this Technoethical N150 Mini Wi-Fi USB Adapter for GNU/Linux today. It says it works out of the box but it doesnt seem to be running at all in Guix. Not even detected. Is there something I should enable? The driver should be ath9k <nckx>butterypancake: A few minutes. Either you've already passed moderation or your mail hasn't arrived yet, & I'll approve it immediately. <nckx>Congratulations! We do strongly prefer ‘free software’ over ‘open source’, though. We don't see the two as equivalent. 😉 <butterypancake>my bad :P I've watched the RMS documentary and everything. Don't know why I can't seem to remeber to call it free :P <bdju>MSavoritias: the tehnoetic site says that USB adapter uses the Atheros AR9271 chipset. I searched guix packages for "ath9k" as you had mentioned it. There's one result, and the package description mentions the AR9271 specifically, so just installing that should do the trick most likely. (and then you may have to reboot as well) <bdju>MSavoritias: that package being ath9k-htc-firmware <roptat>it should probably be part of the configuration somewhere <roptat>it's already in %base-firmware actually, so there shouldn't be a need to add or install it <apteryx>sneek later tell MSavoritias that's strange. My ath9k based wifi adapters work out-of-the-box, without requiring to do anything. <MSavoritias>I installed the package and rebooted but still nothing. Btw why are there not wifi settings in the settings app? <sneek>MSavoritias, you have 1 message! <sneek>MSavoritias, apteryx says: that's strange. My ath9k based wifi adapters work out-of-the-box, without requiring to do anything. <MSavoritias>yeah... i tried also on solus my girlfriends linux. and a live cd of guix and still nothing <MSavoritias>im starting to think there is a problem with the specific usb <MSavoritias>do the wifi settings appear by themselves in settings? <lfam>cbaines: Regarding my botched update of kr-pretty... Err, thanks for fixing it! I don't know how that passed my local tests. I must have dropped that hunk while doing Git surgery. <apteryx>MSavoritias: isn't it listed in /var/log/messages when you plug it? <apteryx>it should show something like: Bus 001 Device 020: ID 0cf3:9271 Qualcomm Atheros Communications AR9271 802.11n <apteryx>(this is with my ThinkPenguin TPE-N150USB, which looks like the same thing) <apteryx>does it on another GNU/Linux PC with a different distribution? (if you have one) <MSavoritias> I tried on my girlfriends linux laptop. It was still nothing. yeah seems like it. well i hope they accept returns <bdju>Is there info anywhere about how to undervolt my CPU on Guix System? I'm getting some thermal throttling that I'd avoided via undervolting on NixOS with a "services.undervolt" in my configuration.nix <apteryx>we see it loads a htc_9271.fw, which appears to be present in the default Guix System configuration <lfam>I wonder, is there a difference between thermal throttling and undervolting? In both cases the system slowed down <bdju>thermal throttling does come with slowdown, undervolting does not inherently negatively impact performance, just reduces power to the CPU which reduces heat <bdju>undervolting in theory prevents the excess heat and thus prevents the thermal throttling, so you stay at your normal clocks consistently instead of being dropped down <bdju>(you can undervolt without underclocking) <lfam>So there's a needle to thread, huh? :) <bdju>I think you can even undervolt and overclock, I'm not an expert on this stuff, but I at least know my ThinkPad gets too hot with normal settings and my dmesg is spammed with thermal throttling messages <bdju>it's a problem I've had with several models, it may be worse from running them in a dock. not sure if that impacts airflow <apteryx>MSavoritias: I confirm it should work out-of-the-box. In (gnu system), ath9k-htc-firmware is part of the %base-firmware, which is the default value of the `firmware' field of the operating-system record. <apteryx>so nothing there's nothing to install or do to get support for your hardware on Guix System. <butterypancake>engineering student here, CPU's are designed to run at a certain frequency. Any faster and you could start getting race conditions (but you can push it). The physical silicon also only activates at a certain voltage. Sometimes you can push that lower too. The silicon sometimes needs a higher voltage to respond quicker, hence why some overclockers also bump the voltage. You can also decrease the frequency if you want to increa <butterypancake>wiggle room you have for lowering the voltage. However, the engineers who designed that CPU did pick a certain frequency and voltage, and straying from that always risks instability. You can indeed both undervolt and overclock, but you get as far in either direction as both of those are introducing instability <bdju>very cool. thanks for the lesson <butterypancake>It's been 40 minutes since I submitted my patch and I still don't see it in debbugs :( I'm getting antsy <lfam>butterypancake: Is it your first patch? <lfam>Or, your first email to that address? <butterypancake>yep. I probably just need to walk away and wait for someone to manually approve :P <lfam>Yeah, first-time senders go into a manual moderation queue for anti-spam. Sorry :/ <lfam>It only happens the first time <nckx>butterypancake: But it's not *in* the queue, is the thing. <nckx>butterypancake: Did you send it to guix-patches at gnu.org? <bdju>I found out which package nixos uses for their undervolt service and I put it on the guix wishlist under the hardware section (in case anyone is looking for something to do) <nckx>The moderation Web UI is a bit slow, maybe that's a hint that the rest is too. <nckx>bdju: Is it that forum-based thing (with a three-letter name that I always forget)? <lfam>I wonder, did it definitely get sent butterypancake? What program did you use to send it? <nckx>My CPU is one generation too new to support it X-( <butterypancake>I sent it to guix-patches, and the outlook web gui shows me that it did send. I used git send-email <bdju>nckx: forum-based thing? if you mean the location of the wishlist, it's on libreplanet <lfam>Okay, if your web UI shows it as sent, then it's probably got sent <nckx>Oh no, that's something else. <lfam>Sorry to break your motivation butterypancake. I know how frustrating it can be <nckx>If it works for me that means a package for you. <nckx>butterypancake: Sometimes (not often) a mailing list just goes out to lunch for a few hours. Let's wait another hour or so. <butterypancake>ya, I tested it by sending it to a second email I have, and it does seem to send. I'll stop worrying :P <emys>nckx, so it seemsthat hg looks in the pythonpath <bdju>nckx: I think I finally get what you meant earlier, there's "tlp". I have that running, actually, and am still having thermal issues <butterypancake>If a made a commit to master, is there an easy way to move that commit to a branch? <bdju>looks like tlp is more about battery life than temperature optimization, based on the website <lfam>butterypancake: `git checkout $branch && git cherry-pick $commit` <butterypancake>They say "You save 3 Watts of battery life", you say "3 Watts didn't become heat". It's all the same really <nckx>bdju: No, it was specifically to undervolt Intel CPUs and it's ‘home page’ was just an old-school forum that dropped tarballs over the wall. Doesn't matter, it was old then and is probably obselete now. <guix-vits>bdju: `cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor` ? <nckx>butterypancake: If you're on the branch, ‘git cherry pick <the commit>’. <nckx>butterypancake: True, but tlp handles a lot more than CPU freq (and I don't know if it touches voltage at all). <nckx>The bad thing about that is we can't use it as native-search-path, but maybe it gives us a way out. <nckx>A matter of perspective. <lfam>I've been wondering, what is the difference between native-search-paths and search-paths? <raghavgururajan>All of a sudden, `./pre-inst-env guix build foo` does nothing. It just stays at loading. <nckx>Opening the ‘home page’ link automatically closes the tab in Ice Cat + uBlock which is… a very bad sign. <apteryx>lfam: me too. From past research, search-paths takes the value of native-search-paths by default, so they act the same except native-searchs-path should be honored in the build container IIRC. <apteryx>I'm not sure any of this is still accurate though, so I'd encourage you to have a look :-) <lfam>I thought it would be something like that apteryx, but the docs are unclear <lfam>Based on how we use the word 'native' in Guix <raghavgururajan>The command `./pre-inst-env guix build foo`executes, but nothing happens. <lfam>Usually that means that foo is already built <lfam>Or, it means that your development environment is not set up correctly <lfam>If you think it should do work and it does nothing, make sure that the environment is configured properly <lfam>Right rekado_, already it's handled on Guix System <rekado_>having an environment variable would be useful for foreign distros <lfam>My patch addresses the foreign distro use case <lfam>I think the patch is sound although it would be great to get another pair of eyes on it *rekado_ cannot be trusted to review C code :-/ <rekado_>raghavgururajan: if nothing at all happens and the command doesn’t terminate you may have a dependency cycle somewhere. <lfam>I put a lot of effort into making sure the heap allocations are big enough or the right size, and that they are idiomatic for alsa-lib <lfam>The old patches from nixpkgs were rather bad, I'm not suprised they removed them <lfam>It would be nice to get something like this upstream in alsa-lib <lfam>I do think it's in the right spirit... upstream has set things up so that work automagically on traditional distros <bdju>guix-vits: result of that is "performance". I suppose then you'd say I should switch modes? <nckx>bdju: Performance hard-locks your CPU to 100% frequency at all times. <nckx>It's almost never a good thing. <guix-vits>bdju: maybe it's hot because of this mode? `cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors`, Try to switch to powersave. IDK, but maybe it's sufficient? <butterypancake>if I'm packaging a release and the author signed the release tag, I should validate that yes? Also how? <nckx>Use ‘conservative’ on laptops. <bdju>Well, if that mode is set in the BIOS, it'd be the same as it was on NixOS where I was fine after an undervolt, but I suppose it's worth a shot to tweak that. <bdju>Looks like my other available mode is "powersave". <bdju>Is this something I can set in my config.scm now? <lfam>butterypancake: Check the --show-signature option of certain Git commands <butterypancake>anyone know any packages that do that? I work well with examples. And certianly not becaue I don't know scheme :P <bdju>My last throttling event was over an hour ago, I suspect I was running updates or something. Although, I'd prefer if it didn't happen even then. <nckx>It's still bad regardless of voltage. The default is set in your kernel configuration (given how universally wrong a choice ‘performance’ is we should probably change that). <nckx>You can't set it on the command line, so your only hope is to write it to sysctl at every boot. I think there's a service for that. <bdju>I started looking through services in the manual. I see tlp has several for setting different power states. Not sure if that's the place I should set it, though. <nckx>If any service ever should handle it it's TLP. ***sputny1 is now known as sputny
<butterypancake>I'm looking at the recipe for guix which I thought signed it's commits but I don't see the verification logic. or is signed commits and tags different? <lfam>You don't verify signatures in package recipes <nckx>butterypancake: We don't check signatures in packages. <lfam>You do it while writing the recipe and then include the hash of the source code <butterypancake>I swore I read somewhere in the manual that you should check the signature on tar balls but I've been trying to find it again and I can't seem too :/ <bdju>This was my attempt at configuring it, but it seems to be wrong: (service tlp-service-type #:config (tlp-configuration (cpu-scaling-governor-on-ac 'powersave))) <katco>i built a docker image utilizing `guix system docker-image`. the image includes packages from some channels in its global packages. however, when i attempt to access the channel packages within the container image, guile/guix cannot find them. even `specification->package` fails to find them. how can i utilize channel based packages in this manner? <nckx>butterypancake: Yes, you should, but manually: by typing ‘gpg --verify’ or so before updating the hash. <nckx>Since Guix checks the hash on all machines, everyone will know they're getting that exact tarball, but checking the signature on each machine would be pointless theatre. <nckx>I.e. ‘got it, shut up’ 😃 <nckx>bdju: Yeah, that ‘#:config’ keyword doesn't make sense. Try without it. Did you find that in docs? <nckx>I just approved a patch adding mspdebug. <nckx>So it was a lunch break after all. <butterypancake>That's me on there! It even made my name purple becaue I'm special :D. I've never seen this before <nckx>Further patches from that address will not be moderated. <bdju>nckx: I actually had an elogind config thing on another line using that and so I just copied it <nckx>bdju: Really, using the (service FOO BAR) notation? That's… not idiomatic, I think. <bdju>Now I've got this error: guix system: error: Invalid value for field cpu-scaling-governor-on-ac: powersav <bdju>this is the elogind line if you're curious: guix system: error: Invalid value for field cpu-scaling-governor-on-ac: powersav <nckx>bdju: ‘maybe-space-separated-string-list’ <bdju>(elogind-service #:config (elogind-configuration (handle-lid-switch 'ignore))) <nckx>our documentation is not the clearest. <nckx>So I'm guessing "powersave" will work. <bdju>I tried adding quotes after the ' and that didn't work, tried removing the ' and it still didn't work <pkill9>why does sudo preserve $PATH by default? <nckx>bdju: Why ' at all? Just (foo "bar"). <bdju>I was again just copying the elogind line <bdju>this is what I've got now and it doesn't work: (service tlp-service-type (tlp-configuration (cpu-scaling-governor-on-ac "powersave"))) <nckx>Since ' is called ‘quote’ in Scheme, watch out with sentences like ‘I added quotes after the ' ’, it can get confusing quickly. <nckx>bdju: Right, but quoting (') a symbol makes sense, quoting a "string" doesn't. Never mind. <bdju>it has not changed in several attempts <bdju>guix system: error: Invalid value for field cpu-scaling-governor-on-ac: "powersave <bdju>oh, actually it changes subtly <bdju>and also I cut off the ending double quote <nckx>‘maybe-space-separated-string-list’ is the worst name ever for ‘a list of strings that we'll separate by spaces as an implementation detail later’. <nckx>I'm sure I needed 2 tries to get it right then. <bdju>by the way, I notice you're using "conservative". I read that option comes from some driver being installed, but one of the files I cat'd earlier only listed two available settings. <bdju>How do I install that drive? <nckx>I use a custom kernel, I suspect that's how. Although Guix's linux-libre should include all governors, they're modular and tiny. <nckx>Oh, you're not using acpi-cpufreq? What are you using? <bdju>I'm... not sure. Where would I check? <guix-vits>`cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver` <nckx>A magical guix-vits appears. <nckx>So I don't know why it doesn't work for you. <bdju>well, I didn't try, an earlier thing just didn't list conservative as an option <nckx>Oh oh oh, this has changed since I last checked it: /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors <bdju>Well, no error setting it to conservative, but then I worry that it could be a silent failure. <nckx>Powersave is fine by the way. <bdju>Do I have to reboot for that to take effect? I'm still seeing the scaling_governor file output "performance" <nckx>Conservative is powersave tweaked just a bit more towards, er, power saving by not upscaling as fast. <nckx>bdju: Have you reconfigured and (perhaps) run sudo herd restart tlp? <bdju>the former, but not the latter <butterypancake>is there a way to replace the default configure flags with my own? A package I'm trying to do only accepts very few flags for its configure <nckx>butterypancake: You'd define your own package ~somewhere~ that inherits from the original and changes only the configure flags. <ryanprior>butterypancake: you mean in a package definition? You can replace the configure step and invoke configure in any way of your choosing. <nckx>butterypancake: Search gnu/packages/*scm for substitute-keyword-arguments for examples. <nckx>They'll also show you how to use (inherit …), but of course that's trivial. <butterypancake>emacs can't seem to define substitute-keyword-arguments for me even though I added the guix repo to geiser-guile-load-path like the info page said too... *nckx doesn't use geiser… <butterypancake>idk, I'm trying to learn scheme. Honestly I haven't use geiser much anyways as all it seems good for is freezing emacs. or maybe that's semantic mode. Whoever wrote the emacs section in the guix manual had a much bigger hard on for this combo than I seem to have :/ <katco>hi, does anyone have any input for my question above? *nckx doesn't use containers either… <guix-vits>katco: seems no (according to backward search) <katco>well i appreciate the falsification of input at any rate :) <rekado_>katco: the docker image is just a nested tarball. Have you looked inside to see if it contains what you expect? <katco>the store contains the packages, but i can't figure out how to reference them <rekado_>what do you mean by “the store contains the packages”? <rekado_>how is that related to the container you built? <katco>i.e. the assets are present, but i can't do say `(specification->package "my-channel-package")` <katco>within a guile repl, or in a package specification <rekado_>katco: can you show us “guix describe” <rekado_>the store is only a cache. If you have no channels enabled in your current version of Guix you won’t have access to channel packages. <rekado_>even if their outputs might be cached somewhere <katco>the guix which produced the container image contains the channels, but the guix container it produces apparently does not <rekado_>was this “guix” command obtained with “guix pull”? <rekado_>wait, so you put Guix inside the container as well? <katco>it was obtained by including the `guix` package within an `operating-system`'s package field. <katco>i want to be able to pipe guix commands through this container, such as `guix build`. this is a common scenario with buildboxes. <rekado_>you would need to arrange for /etc/guix/channels.scm to be installed in the container <rekado_>and then you’d need to pull in the container to get that channel-augmented version of Guix <rekado_>the alternative is to build a custom “guix” package (instead of the one from gnu/packages/package-management.scm) that includes the modules provided by your channel(s) <katco>`/run/current-system/channels.scm` is correct within the container. i haven't done a pull yet. but that should be doable: perform a pull and then snapshot the container image <katco>if i can get this working, it will be a blog post <butterypancake>ok, so I don't think I know how to use substitute-keyword-arguments. I instantly got to 100% CPU usage and my computer froze for a minute. <butterypancake> (arguments (substitute-keyword-arguments (package-arguments opendoas) ((#:configure-flags flags) flags))) <apteryx>butterypancake: probably! Why are you trying to reference opendoas's own arguments within the opendoas package definition? <butterypancake>idk, people told me to use this. I think it's probably too much. All I want, is to throw away all the default configure-flags and give it my own <butterypancake>opendoas has a very limited configure script that won't accept the defaults <apteryx>othen you can simply use the argument: #:configure-flags '(your flags) <butterypancake>the defaults causes the configure script to throw errors and won't continue <apteryx>OK, then what I'd do is replace the configure phase altogether <apteryx>grep for '(replace 'configure' in the sources, you'll find plenty of occurences <nckx>butterypancake: (arguments #:phases (modify-phases %standard-phases (replace 'configure (lambda _ (invoke "configure" "foo" "bar" … <nckx>butterypancake: substitute-keyword-arguments is to modify the #:configure-flags of an existing package, not those appenden by the build system, there's no way to avoid those without replacing 'configure. <butterypancake>how do you guys look up documention? I went to use geiser to look up invoke but apparently geiser is useless (or more likely misconfigured). I read the first little bit of the guile info pages but honestly those could use some work <mbakke>pro tip: using (replace 'configure (lambda* (#:key configure-flags #:allow-other-keys) (apply invoke "./configure" configure-flags))) will let you keep using #:configure-flags without the "extra" flags added by gnu-build-system <apteryx>butterypancake: there are two layers of code involved 1) the upper level where the packages are defined, and 2) inner level that is executed in the build container <apteryx>often the bindings such as invoke that come from (guix build utils) are available only in the scope of the build code. <apteryx>Geiser only finds stuff available in scope <butterypancake>i ran (add-to-list 'geiser-guile-load-path "~/src/guix") so I though geiser might be more useful. <apteryx>It *is* useful after we've groked how it works :-) give it some time <apteryx>what I like to do is launch Geiser with C-c C-a <apteryx>it starts the Geiser REPL and loads the current module <apteryx>If you need more bindings (such as those of in a #:modules argument), you can ,import them in Geiser <apteryx>after that the navigation (M-. and M-,) and documentation C-d d should just work <butterypancake>I guess I'll look into it. It might be worth it to actually learn some scheme and some scheme related tools instead of just glueing random things together <butterypancake>apteryx: could you share the function that starts the geiser repl and loads the current module? <apteryx>or M-x geiser-mode-switch-to-repl-and-enter <butterypancake>thanks! It even comes with evil bindings from somewhere. g Z for me <butterypancake>oh, I probably just didn't tell it where glibc is. I should do that <butterypancake>hmmm... it knows where glibc is if it's asking the environment variables <apteryx>I don't know! Are you using the gnu-build-system? <apteryx>guix-devel-mode comes from emacs-guix <jonsger>is there a way to bring libgcc, libstdc <apteryx>I think you want to --ad-hoc gcc-toolchain <apteryx>but this is usually implicit if you 'guix environment some-package' if some-package uses the gnu-build-system for example <apteryx>OK. Then gcc-toolchain is what you're after