IRC channel logs
2023-04-18.log
back to list of logs
<telmo[m]>In guix its possible make the guix package manager building softwares with other flags? <apteryx>tschilptschilp23: I'll try having a look a bit later <Guest19>telmo[m] what you mean with similar to gentoo? you mean use flags? <mekeor[m]>telmo: currently, you need to write a couple lines of scheme in order to apply custom configure flags. there is a patch debbugs #62551 that features a cli-option for this. <mekeor[m]>see also `info "(guix) Package Transformation Options"` <telmo[m]>Guest19: I like building all with my personal flags <mekeor[m]>as i said, there is a patch currently under review. <Guest19>would be cli only anyways. if you want to have config with your flags lust like it is in gentoo, I would say no. Technically it is possible but no one is working on it <Guest19>also gentoo is smart, if you customize your kernel and install a package that requires something, it warns you, guix will not if you customize your kernel <mekeor[m]>you'd just write a little wrapper around the package, no? <Guest19>well, he probably has global flags as well. i am just saying he will never have the experience as in gentoo <mekeor[m]>maybe you could map a transformation over a list of packages :) <mekeor[m]>so, i have this package that uses rust, gtk(4) and meson. i think i need to use cargo-build-system because otherwise i can't specify any cargo-deps... <Guest19>worst case would be trivial-build-system. that means you need to do it manually <GNUtoo>zacchae[m]: for (1) it didn't work <GNUtoo>I've tried very old profiles from January and they are still somehow broken <GNUtoo>I've tried stracing guix with 'strace -e openat -ff guix shell -D guix 2>&1 | grep -v gnu/store' and I didn't find anything interesting <GNUtoo>The cache files it tries are things like '/run/current-system/profile/lib/guile/3.0/site-ccache/gnu/packages/ocaml.go' <zacchae[m]>GNUtoo: Old grub entries don't work?!? Never had that problem, but at that point, I would do a fresh install... <GNUtoo>I'll write to the mailing list because I'll end up breaking my systems again and again otherwise <GNUtoo>I already had that issue once and I think I managed to fix it by following some advises but finding them again would be very very long <mekeor[m]>is anyone working on antioxidant build system? or is it doomed to bitrot? <mekeor[m]>whereiseveryone: yea, maximed hasn't commited anything in 5 months or so <mekeor[m]>theres a thread in the mailing list about this question <bjc>well, i couldn't figure out how to get pre-inst-env working again with core-updates, but at least rolling back your entire operating system in guix is trivial <jgart[m]>mekeor: I mostly ask because I don't fully understand how it works yet and was hoping for a TLDR ;() <jgart[m]>lfam: Katherine Cox-Buday is 1+ing my patch in 62906 <jgart[m]>Would you be able to review that one and merge if fit for merging. <jgart[m]>I can't guix pull to latest because of it :( <bjc>jgart[m]: was that supposed to be directod to me? i don't remember being involved in python stuff except for an issue with zip creation before 1980 <bjc>or am i missing some context here? <apteryx>sneek: later tell tschilptschilp23 audacity should be fixed; 3.3.0-beta-1 <apteryx>jgart[m]: where does it get into the dependency chain of guix? <bjc>huh. ‘./pre-inst-env guix offload test’ is looking in /usr/local/etc/guix instead of /etc/guix <whereiseveryone>apteryx: hi, where does what get into the dependency chain of guix? I lost the context <apteryx>bjc: that's because you forgot the infamous --sysconfdir=/etc <bjc>well the instructions only talk about localstatedir =P <bjc>i just assumed guix didn't bother to use PREFIX =) <bjc>gimme a tick to find them <apteryx>it's not useful outside of offload or authorize, but yes, that'd be a useful addition <bjc>i'd say yes, since it's already telling you to use /var <bjc>22.1 Building from Git has the configure flags <apteryx>whereiseveryone: I read from you that 'guix pull' was broken becauso of the python-trio test suite failing or something <apteryx>I don't connect 'python-trio and guix pull', but they must be somehow? <jgart[m]>apteryx: sorry, I'm back in element now. I also use the whereiseveryone username <jgart[m]>They are connected only in the sense that when I ran guix pull this morning it failed with an error complaining about python-pytest-trio failing <jgart[m]>due to the tests failing in python-pytest-trio <jgart[m]>So, it prevented me from running guix pull in that event <jgart[m]>I looks like the same thing happened to Katherine Cox-Buday 9 hours ago <jgart[m]>Authenticating channel 'guix', commits 9edb3f6 to 774a6fb (83 new commits)... <apteryx>I think i've ran guix pull a few times today without encountering it <jgart[m]>Computing Guix derivation for 'x86_64-linux'... / <jgart[m]>apteryx: build of /gnu/store/lrdn36j73a764k5i8c6sq9klvvrzsr69-python-pytest-trio-0.7.0.drv failed <apteryx>it must be caused by some channel, because I don't have that; can you move your channel file and try again? <apteryx>or possible going from an older version of guix? <apteryx>python-pytest-trio is indeed broken, but it isn't a dependency of 'guix pull', so doesn't break it for me <jgart[m]>I'm pretty sure that tests are failing for pytest-trio at 0.7.0 <apteryx>I happened to have update pytest-trio to 0.8.0 on core-updates (locally), I'll see if I can cherry pick that <jgart[m]>If a package breaks in Guix it doesn't prevent you from pulling to the latest where that package is broken? <bjc>guix pull just fetches and authenticates the latest definitions <apteryx>if it's package definition (syntax) is broken at the Scheme level, this will break guix pull <jgart[m]>There's an issue open for it in upstream. <bjc>will it? i've never seen that happen, but it surprises me <apteryx>but if a packages happens to just not build (and isn't part of the dependencies needed by guix pull, e.g. guile), it doesn't matter <jgart[m]>So tests should probably be disabled on pytest-trio until that gets fixed <apteryx>guix would be broken 24/7 otherwise ^^' <apteryx>I'm a bit fuzzy as to what enters the dependency closure of 'guix pull' itself, we'd have to study the derivations involved <bjc>why would guix pull even look inside a random package scheme file? doesn't it just pull from git and authenticate commits? <apteryx>but I'd think mostly Guile, Guile extensions and their closure <jgart[m]>apteryx: would you be interested in giving a talk about the ideas in antioxidant to date? <bjc>i could see subsequent pulls failing, at least if the error is in guix modules <jgart[m]>I've hosted Arun Isaac, singpolyma, and charje so far <jgart[m]>Looking for others to talk about interesting stuff <bjc>anyway, a python package almost certainly has no bearing on how guix operates, i hope <jgart[m]>But you are the only one that is able to do it as know one else is working on antioxidant lol <jgart[m]>Well if you don't want to that's cool too <jgart[m]>The idea is not to present anything that is even near finished but just to casually discuss the ideas and concepts and goals in the effort going into the future <jgart[m]>And the state of things for people interested <jgart[m]>Or for people who might also want to help out in some way in those efforts <jgart[m]>Maybe there are some rustaceans out there who also don't like cargo and want to oxidize it with guix... <bjc>oh neat, i'm getting icecat substitutes from core-updates. i thought that was still broken <bjc>wow. only two broken packages in core-updates for my home config, and one is a dead simple patch. i was expecting much worse <apteryx>the_tubular: for your own projects... or for special needs such as a static binary that is used at early boot <apteryx>it's pretty niche and useless for the most part in the everyday operation of the Guix System <apteryx>Guile for example has to run "by itself", without the glibc runtime available when it boots Guix System <apteryx>(my vulgarised, possibly inaccurate understanding :-)) <apteryx>ah, probably more accurately, without the dynamic loader, which would require facilities from the kernel perhaps? <podiki[m]>what's the most recent pytest change, it was bumped to latest version? (looking at breakages on master) <podiki[m]>ACTION gets some low hanging python fruit on core-updates... <podiki[m]>ok, python-urllib3 can be updated and that fixes some builds but also means ~1k rebuilds and possibly other breakage <podiki[m]>needed, as we have python-crpytography updated and that's what is causing some errors looking like from other packages but ultimately is urllib <podiki[m]>pushed urllib update and another fix; older pythong-google-auth-1 is still broken even after adding in missing python-mock <podiki[m]>bedtime here, but think it is due to newer python-cryptography <podiki[m]>looks like just some older python-google api stuff uses it, but haven't looked in detail <podiki[m]>new urllib should fix failures from the newer python-cryptography, will have to see later if it broke others though <efraim>podiki[m]: the python google stuff is different between versions 1 and 2, I ran into that with some other packages <nutcase>hi all, I installed the package 'anki' and I think that something is missing. I haven't used anki before, therefore I'm not sure, what exactly is missing. The GUI doesn't show labels on buttons (although the profile selection window is fine). Any ideas what could be wrong? I'm on i3-wm, if that is relevant. Screenshot: https://i.imgur.com/NmOLuca.png <efraim>we did mips64el with a 64bit kernel, right? I'm adjusting the configure-flags for openssl <civodul>i wouldn't bother too much though :-) <abrenon>nutcase: not sure you're missing anything, for what it's worth I get the exact same window when spawning one too <abrenon>I used to use anki many distributions ago but haven't used it since I run guix so I don't know what's expected <abrenon>so I guess it's "normal" until you install some card sets <abrenon>ok there's definitely something wrong with Anki, the squiggles really are buttons and everything still remains without labels even after loading a deck <abrenon>the person suspects a QtWebKit bug, do you know this lib ? can you investigate the issue ? <minima>hi, i'm launching './configure --localstatedir=/var' and i get this error about the guild binary not being found - although guile is installed <minima>is there anything obvious that might be missing in my env? <minima>sorry, i should have given more context <minima>i'm launching ./configure from within a checkout of the guix repository <minima>the bootstrap command completed successfully <andreas-e>You can try to run "guix shell -D guix" to get into an environment for Guix. I am not sure it contains everything needed for compiling from source, but it might contain a few packages that you forgot. <minima>hi andreas-e, yeah, i've been using 'guix shell -D guix help2man git strace' but that still complains about guild <andreas-e>Can you check your setup with things like "which guild", "type guild" and "echo $PATH"? <minima>hm, yes, guild is regularly installed, apparently: which returns it's path (from the store) and the command can be regularly launched from the command line (from the same terminal where the configure command fails) <minima>hm there might be a problem with the system guile (the one installed under debian) being picked up instead of guix's guile... let's see what happens if i get rid of debian's <minima>ok, weird, but at least i think i solved it; i removed all references to /usr/bin from my PATH so that the system's guile doesn't take priority over the guile installed via guix <abrenon>have you tried with the `--pure` option for guix shell ? It's supposed to hide away everything not specifically requested for the environment so I think it should have done automatically what you had to do manually editing the PATH <minima>abrenon: oh, true... i should have tried that... <sammm>hey - probably a simple one, I have installed a custom channel into both ~/.config/guix/... and /etc/..., but _only_ running guix under root will seem to query the non standard channel. any tips? <sammm>oh, and guix pull under my user _will_ query the non standard chnanel <Guest19>i am trying to package pcsx2 but I can't run a game since it has problems with the gpu. There is no console output on why this is the case either. How can I debug it? <minima>sammm: is the custom channel authorised? <GNUtoo>Guest19: are there free games with source code that could be modified for instance to draw a pixel and then you could see that pixel? <sammm>minima: I have the introduction object defined <minima>sammm oh, i see, that's the only thing that comes to mind, sorry <GNUtoo>For the custom channel I'm not sure but maybe using 'sudo su -' somehow could work (someone gave me that command for doing a system reconfigure as root), but I'm also not familiar with sudo or su in guix so I've no idea if this creates issues or not. <Guest19>GNUtoo I doubt. The problem isn't the game itself but pcsx2. Doesn't find icons either for the gui <andreas-e>samm: I think you first need to do a "guix pull" with the new channel, and then the other guix commands will see its contents. <GNUtoo>Guest19: for icons it seems to be a common issue in Guix, I'm unsure how to fix it, maybe just installing more dependances / icons fixes it <GNUtoo>For instance I use claws-mails and icons are fine, but in terminator some icons are missing in my system <adamnr>Hi all, I'm trying to use guix shell --container --network --emulate-fhs but when I run a command in it sudo make .... I get the error sudo: /bin/sudo must be owned by uid 0 and have the setuid bit set, any ideas how to work around this? <efraim>adamnr: can you call /run/setuid-programs/sudo directly from inside the container? <abrenon>is that supposed to be inside a container ? I can reproduce the issue, and don't have any /run/setuid-programs directory, either with or without --emulate-fhs <cbaines>qa.guix.gnu.org was building core-updates, but I stopped it a week ago since there was some changes leading to lots of builds pushed <cbaines>does anyone working on core-updates know if the big changes are now done and it's just fixes being made? <cbaines>(I'm asking because then it would be good to have qa start building it again) <civodul>cbaines: i think world rebuilds are supposed to be done long ago <civodul>but with 22K packages, there's a whole spectrum of "world rebuilds" <apteryx>cbaines: I'm holding onto a couple patches which rebuild perhaps half of the world, waiting to be able to build gnome to push it <cbaines>apteryx, OK, that's good to know, feel free to let me know when you've pushed those if you'd like to <cbaines>I might queue up some powerpc64le builds manually since there's some capacity in the bordeaux build farm for that system <apteryx>civodul: thanks for the few patches fixing regressions/bugs in the SSH/offload department. I'm reconfiguring my remote with it, I hope it'll stabilize things. <apteryx>Not sure why it had suddenly gone downhill <apteryx>no, it seems more GSSH_SOCKET errors and timeouts <apteryx>oh, is this the one where large transfers get interrupted? (reading) <apteryx>it typically happens when lots is going on at the same time (transferring results while building other things), but it seems transfers are what triggers it <civodul>so the bug above would only occur if you're running "guix-daemon --debug" <civodul>the connect* timeout you show is something that happens due to ci.guix being too loaded i believe <civodul>but see 8136c1578eadbd0630695d86d52b6227db791539 <cbaines>I'm not quite sure how berlin can be too loaded with the resources it has <apteryx>is this substitute script invoked by the daemon, or by my client? <civodul>'guix substitute' is invoked by guix-daemon <apteryx>OK, so to try the fix, I'd have to 'make update-guix-package' (or has it already been done with the fix), then reconfigure my box, then 'sudo herd restart guix-daemon'. <civodul>i didn't update 'guix' because i thought this can wait <qhong>Hi! anyone managed to get X11 emacs 'alpha-background working on guix? <qhong>It does something on PGTK emacs but I use EXWM <civodul>qhong: hi! i used EXWM but i haven't tried that <bjc>i asked on the ml, but didn't get a response yet: is there a blessed way to set the system time when building a package so that it can be something other than 0 epoch seconds? <bjc>i have two packages (and there are probably more) that need it set to at least 1980, and the code i have to do that is not amazing <bjc>(this is for core-updates) <qhong>civodul: hi fellow emacser! Can you try (set-frame-parameter nil 'alpha-background 0.5) to see if it does anything? This might also need a compositor running <podiki[m]>qhong: I noticed the same thing last I tried, on X as well: only pgtk did something but was buggy, this is for emacs-next <bjc>it doesn't do anything for me with wayland+sway and emacs 28 <civodul>but then maybe it depends on what the root window is? <civodul>i mean, there's nothing below the Emacs frame, right? <podiki[m]>Supposed to just give alpha to the background not the text for example <podiki[m]>But yes I believe it needs a compositor for the actual transparency <podiki[m]>I tried to track down what was going on here, as it should work on X and does on other distro I tried, even changed all our build options to match and still didn't <podiki[m]>So I was down the rabbit hole of cairo and other deep dependencies but didn't figure it out <qhong>civodul: if you have a compositor it should blend it with the black null abyss under emacs <podiki[m]>This was some months ago though, haven't looked recently <qhong>I tried emacs 29 and HEAD (30), neither work <podiki[m]>As an eye candy lover would be great if it worked, seemed something on guix's end from what I could tell <podiki[m]>efraim: on older python google; yes, wasn't sure yet if still supported older version or if needed for other packages still, will have to investigate <nutcase[m]>abrenon: Thank you for confirmation and pointing me on the issue. I am not really familiar with QT/WebKit. <mrvdb>are there any other powerpc64le users in here? i'm interested how/to which extend they use guix, things have been getting worse for me over time. (mostly dependencies not building) <civodul>apteryx: i'll take a look, it's become a classic <janneke>apteryx: thanks for fixing git-timemachine (some time ago)! <janneke>apteryx: i got "command-execute: Symbol’s function definition is void: define-transient-command" <minima>say i have a local checkout of the guix repo, with a personal branch that includes some additional packages; in order to reconfigure my guix home, do i simply add --load-path=/my-local-checkout to the reconfigure command? <apteryx>janneke: I'm lacking some context; is it broken again and you're trying to fix it? <abrenon>nutcase[m]: me neither alas : ( I wish I could investigate that but I don't have much time or need for anki so I'm not very likely to work on it <apteryx>civodul: how do you debug the 'fold-available-packages with/without cache' issue? <janneke>apteryx: hmm, it was broken for me, i found your emacs-transient update and was sure it was fixed by that --- <janneke>but somehow it breaks again for me now :-( <janneke>ACTION has switched to guix home too ... <apteryx>civodul: there used to be a (pk (find-duplicates from-cache)) in the test <apteryx>ACTION has never used emacs-git-timemachine :-) <apteryx>the emacs-transient problem I caught in magit <apteryx>when trying to configure a git remote <janneke>ACTION wondsers how someone could live without git-timemachine ;) <civodul>apteryx: pk 'duplicates1' and 'duplicates2' <civodul>usually this is caused by the introduction of a package duplicate (same name/version, but not eq?) <apteryx>ACTION tries with duplicates1, which should be equivalent to the old (pk (find-duplicates from-cache)) <ngz>janneke: The `emacs-git-timemaching' perfectly lives with an outdated source URI, tho ;) <ngz>janneke: I don't know if that will fix your problem, but emacs-transient needs to be added to propagated inputs, indeed. <janneke>ngz: i'll try it, and fix the source URI while i'm at it <jgart[m]>shipping python interpreter with xonsh and xontribs to a foreign distro <apteryx>civodul: ah, so the culprit this time is python-pillow <apteryx>jgart[m]: that's a good use case yes <apteryx>especially now that it can target both .deb and .rpm systems natively <civodul>apteryx: right, it doesn't need to be public <rovanion>Funny thing, I'm also fighting pythons with pillows right now. <rovanion>Not that funny, but python-pillow is one of the dependencies to a package I'm working on for an entirely different package manager. <rovanion>Though I now appreciate the hard stance of packaging every single python package as its own package. <apteryx>civodul: one of the failure has to be with "package gvfs@1.50.3 does not support i686-linux" <apteryx>I think that may be because python-cryptography now requires rust <apteryx>and rust is yet to become available on i686 in guix <apteryx>do we really want to do this kind of test in the unit tests though? <apteryx>it's very expensive in terms of fetching the gnome deps to the test-tmp test store <apteryx>ah, it just lists them! it uses -n (dry-run) <janneke>sadly, adding (propagated-inputs (list emacs-transient)) to emacs-git-timemachine does not fix it <civodul>apteryx: right, tests don't build anything in test-tmp beyond guile-bootstrap and make-boot0 <apteryx>ugh, why is our main 'samba' variable not grafted <andreas-e>apteryx: I noticed you updated python-pytest-trio on master beyond the version in core-updates. It is okay if I merge master into core-updates later? Or does it interfere with your python packaging for core-updates? <podiki[m]>apteryx: you mean my samba patch where testing I dropped the selftest configure flag and python-cryptography input for i686? <podiki[m]>smaba and pinned ordering changed in c-u vs master <apteryx>OK; I'll start fixing it on master, then look at cu <podiki[m]>on samba: I think c-u ordering is the more recent <janneke>ACTION pushes fix for emacs-git-timemachine to master <whereiseveryone>Is anyone working on a way to do `guix refresh -u` on arbitrary commit hashes? This could be useful for updating emacs and common lisp packages <apteryx>ugh, sphinx depends on python-cryptography <AwesomeAdam54321>whereiseveryone: I don't think anyone's working on it currently, since checking if there's a newer commit available requires knowing the whole commit history <apteryx>hm, it's not like GNOME on i686 is supported anymore (given rust in GDM and places), so I'll drop the test from guix-system <AwesomeAdam54321>unless there's a way to only get a range of commits from a specified commit to HEAD <AwesomeAdam54321>apteryx: I think it would be better to fix the bug blocking mrustc from being built on i686 <whereiseveryone>AwesomeAdam54321: I wan to be able to just do `guix refresh -u python-cryptography --hash=3f00e4d8c618b363bc8421aae586c897602f5af5` or what not <apteryx>AwesomeAdam54321: agreed. that's longer term goal than fixing the test suite though. <whereiseveryone>because right now it is painful to update packages that are not versioned <whereiseveryone>I might just have `guix import npm ...` call that script as a temp hack... :) <apteryx>AwesomeAdam54321: do you have skills in C and a beefy machine that could be put to good use to attempt to have mrustc build on i686? if so, I encourage you to try <apteryx>I think some words were shared on the ML about disabling debug symbols may be enough, GNUtoo had dabbled with that IIRC. <apteryx>podiki[m]: your patch will be applied to master shortly, after I verify that the guix tests run OK <apteryx>but trademarks are supposed to be marks, rather than words, no? <apteryx>the stylized (artwork) version of a word, I reckon? <bjc>but it's context dependent. you can have a cereal called "rust" and the only other infringers would be cereals or similar items <bjc>the rust foundation was (temporarily) pushing a set of unenforceable rules <podiki[m]>apteryx: should be same fix on master, but I don't think that patch will apply as is due to the samba and pinned difference; I can check later this afternoon if it is not obvious <apteryx>podiki[m]: I've rewritten the first to use package-transitive-supported-systems and applied it to samba/pinned as well. The second (the update) I had to apply by hand. <apteryx>only FAIL: tests/guix-pack-relocatable.sh failed, I think because of running the test in parallel <civodul>emacs-exwm fails to build on core-updates: (error "Unsupported structure content: <length>") <podiki[m]>apteryx: thanks! That should help a little chunk of i686 and wine built for me last I tried <civodul>jpoiret: dunno, during the build phase? <apteryx>hm, tests/guix-pack-relocatable.sh still fails <apteryx>build of `/gnu/store/dc44cbxn0v5n35kqwikdkcw1q211icwh-groff-tarball-pack.tar.gz.drv' failed <apteryx>'make check' should be all green now <podiki[m]>apteryx: I can look into random python packages later today, after you push your changes (what are the big ones?) <minima>so, i updated my home with 'guix home reconfigure --load-path=<path-to-my-guix-checkout>/gnu/packages/ config.scm'; does this look ok? security wise, i suppose '--load-path' doesn't add any risk, if the repo checkout has been checked with a 'make authenticate'? <minima>i did get a bunch of warnings though with regard to some paths not being as expected <minima>(e.g. warning: module name (gnu packages zwave) does not match file name 'zwave.scm') <apteryx>my offload problem seems like it may just be autossh zealously aborting the connection... not sure. <apteryx>that's new behavior here (openssh connection to my remote machine gets aborted all the time) <andreas-e>apteryx, podiki[m]: Okay to merge master (in particular the python packages) into core-updates later today? Or will you just cherry-pick the python packages? (I am a bit afraid of mixing the samba pins in a merge.) <podiki[m]>andreas-e: I think apteryx can speak better to the samba pin situation now, but I think we were gonna have the same i686 fix on both branches, just ungrafted in core-updates? <apteryx>that's the idea yes, there's no graft on core-updates <podiki[m]>so once the changes is made on core-updates, I think you'll just want to make sure the merge doesn't revert to the raft <podiki[m]>my other python changes were on core-updates already; I'll look there later to see what else I can fix <podiki[m]>(samba was special in that it was broken for i686 on master as well, due to python-cryptography update) <andreas-e>Yes, that would be most welcome; as you have worked on the changes, it will be fresh in your mind what the desired outcome will be. Thanks! <andreas-e>I mean, it would be most welcome if you did the merge. <apteryx>I'll happily take care of the merge, np <podiki[m]>thanks to you both! (and I was worried this samba situation was going to cause merging issues so I'm glad it'll be done before we forget the details) <efraim>were we supposed to keep an older pre-rust python-cryptography (36?) or no because of the security implications <podiki[m]>that's the question now I think, the python google packages (the v1) I suspect won't work with newer cryptography <podiki[m]>and I too wonder about security implications of keeping old cryptography library <cbaines>when installing Guix with btrfs, I'm having trouble with the filesystem being detected. On boot it's scanning for the filesystem but not finding it, I'm using the UUID from blkid, which I hope is correct, any ideas? <cbaines>This sucks since I guess I'm going to have to install from scratch to attempt again <cbaines>I ended up using uuid's in the config since guix system init complained that /dev/sda3 didn't exist, because the installation system viewed it as /dev/sdb3, which I'm also not sure how to handle <jackhill>cbaines: I've had sucess with btrfs inside lvm (and dmcrypt) using uuids. I tend to copy them from /dev/disk/by-uuid <jpoiret>I wonder if we could use cgroups to ensure all builds use a manageable amount of memory? Some build processes just don't go through on my poor laptop <zacchae[m]>Seems like the build farms aren't keeping up with the rate of guix updates (at least for aarch64). Is this a short term problem, and I should just try to update later, or do I need to figure out how to cross-compile from another machine? <andreas-e>The build farms work well for x86_64 and i686, and I just tweaked powerpc64el so that it will catch up soon. <cbaines>zacchae[m], what substitutes are you missing? <andreas-e>The situation for aarch64 is indeed not as good, recently we had only one machine behind ci.guix.gnu.org. Today there are three, one more is broken and will be repaired. <cbaines>there was a dip after the staging merge, but the substitute availability should still be quite high <andreas-e>I hope that the situation will become better. <andreas-e>Instead of doing a "guix pull", you could try, for instance "guix pull --commit=..." with a commit from a few days ago. <zacchae[m]>I'm using bordeaux as well. qt<everything> seems to want to compile for me to get qutebrowser on my puny Librem. I even had to compile emacs on an hours old guix pull!! <cbaines>autebrowser does indeed not look to have been built yet, there's probably some room for improvement in the prioritisation <apteryx>cbaines: that should be OK (using the 'UUID' as reported by blkid) <apteryx>are you perhaps using drives larger than 2 TiB on a legacy BIOS machine? <zacchae[m]>andreas-e: I think I will do that. The only way I know how to do that is to clone guix and do a git log. It seems like there is a use case here that could be added to guix <cbaines>apteryx, this is a 500G SSD in an Overdrive 1000 (using EFI) <cbaines>unmatched-paren, I think you mean distracting, but yes, I get what you mean :) <jackhill>so that's why a bunhc of stuff is missing <zacchae[m]>I would like to do a "guix pull a recent update, but old enough that substitutes work", but then again, a better solution is probably to upgrade the build farms. <zacchae[m]>Wait, is this a money thing? Is there a place I can send money to get more reliable aarch64 substitutes? <cbaines>the bordeaux build farm only started to build the changes in the staging branch once they hit master <cbaines>ideally things will be better in the future if the builds happen before big sets of changes are merged <apteryx>zacchae[m]: haha, there's no such 'pay to get a better service' from GNU Guix at least, but if you want to benefit the build rate you could purchase some ARM hardware for the build farm <andreas-e>zacchae[m]: I suggest you try commit cbba52a from April 13, just before the staging merge, I think. <andreas-e>Click on the screen symbol for the dashboard, then select aarch64 and click "Go". <podiki[m]>cbaines: btrfs here without problem, using subvols and going by file-system-label (uuid for the fat efi partition) <jackhill>zacchae[m]: are you using Guix System on your librem, or on top of PureOS? <andreas-e>cbaines: Exciting! Is it not too expensive to do the real time updates? <cbaines>andreas-e, are you talking about the activity thing? <zacchae[m]>apteryx: "buying arm hardware for the build farm" is more what I had in mind, but I would prefer to just donate money, and have it go to expanding arm capabilities <andreas-e>I think the limiting factor is less money, but people power to manage it. <jackhill>do we have good, recommened arm hardware for the build farm? I fear much of the new fancy stuff won't work with linux-libre <zacchae[m]>jackhill: PureOS with guix home on top. Had some hiccups, but was able to make it work with the caveat that I had to "disable" .guix-home/profile/etc/xdg <cbaines>andreas-e, more work definately needs doing on it, and I've got some concerns regarding the long lived HTTP connections, but I think they should all be solvable issues <jackhill>zacchae[m]: ah cool. I'd love to be able to use Guix system on something like that, and am still learning guix home. <zacchae[m]>jackhill: This is exactly why I would rather give them money to buy hardware than give hardware. How do I know it will be useful? <adamnr>efraim: I get the following error: sh: /run/setuid-programs/sudo: No such file or directory <adamnr>abrenon: if you use --emulate-fhs then it has to be in a container <apteryx>zacchae[m]: donating to the FSF (they have specific per-project funds, e.g. for Guix) or to Guix Europe, depending on what's closest to you (cheaper for the transfer) is a way to contribute to that. That money is typically used to purchase hardware. <podiki[m]>well, seems like the python-urllib3 update fixed more than it broke? what is the magic for doing two cuirass evaluation comparison? <lilyp>Anyone else using evolution and getting blank emails? <jpoiret>has anyone worked on the zig segfaults on core-updates? <andreas-e>podiki[m]: Leo Famulari had a magic line for QA. On CI I think it is currently not possible. <andreas-e>Then one needs to find commits that are evaluated there. core-updates is not part of it, I think. <podiki[m]>well my casual glance at the failures post urllib3 update were not new, but i didn't look at all <cbaines>data.qa.guix.gnu.org covers core-updates, but it doesn't have build information from ci.guix.gnu.org <cbaines>so the comparison won't have much information <podiki[m]>after core-updates I think we'll want some updates to the contributing manual to further highlight all this cool stuff <cbaines>but I want to build out the qa-frontpage so that it highlights the useful information, rather than people going directly to data.qa.guix.gnu.org <andreas-e>But where do I see the list of evaluated commits from core-updates? <podiki[m]>a nice qa-frontpage sounds great, sadly i'm not great at data visualization so i have no requests/tips <andreas-e>Ah, right, I copy-pasted and used /1/ in the middle instead of /2/! <podiki[m]>but at a glance sense of recent failures will be helpful <andreas-e>cbaines: You can drop the staging branch now. <cbaines>you mean from qa.guix.gnu.org andreas-e ? <andreas-e>jpoiret: zig has received no attention, I think. <andreas-e>From everywhere :-) But I mean qa.guix.gnu.org. <cbaines>andreas-e, right, the / page is still very much a work in progress, but yes, I'll look at removing staging <Guest19>user host = (root) NOPASSWD: /sbin/reboot how would I do this for Guix since sbin doesn't exist? <Guest19>running a specific sudo cmd without password* <euandreh>Guest19: use /run/current-system/profile/sbin/reboot instead of /sbin/reboot <sharlatan>If I'd like to send patch to core-update how to name it? <sharlatan>There is astronomy casacore wich can't be upgraded to the lates due to issue with GlibC which I guess resolved in core-update. <jpoiret>sharlatan: core-updates will currently only see fixes, not new package upgrades <jpoiret>it's in the process of being merged so you might end up being able to upgrade it on master soon <sharlatan>It would be nice to have some questianry in dev mail list on which scientific field Guix is in use. My hamble aim to make ot popular among astronomers and astrophysics ^.^ <zacchae[m]>sharlatan: FYI there is also a guix-science@gnu.org mailing list <sneek>Welcome back civodul, you have 1 message! <civodul>well, the time for the CVS update to propagate... <civodul>jpoiret: oh, so at least we could keep the old version of emacs-xcb around <apteryx>civodul: I've reconfigured berlin, so we should have your latest fixes for the substitutes <andreas-e>On sjd-p9, I get the following from cuirass: warning: low disk space, doing nothing <andreas-e>There is plenty of space in /gnu, and 2.8 out of 15GB on /. <andreas-e>Hm, not enough space for building in /tmp, I suppose. <mekeor[m]>hello. i'm trying to run a binary with `guix shell ... gcc-toolchain gcc -C -F -- ./the-binary` but i still get "libgcc_s.so.1: cannot open shared object file: No such file or directory". any ideas? <andreas-e>civodul: Can I safely delete /var/guix/substitute ? 