<jab>Guest36: can you use a pastebin ...maybe debian pastebin and put your code in it. <jab>Then link to said code. <jab>Guest36: I like your host-name! <Guest36>thank you! :))) I always use it for my Linux drive <jab>Guest36: try a "duff /run/current-system/configuration.scm /path/to/your/config.scm" <jab>/run/current-system/configuration.scm is what guix system is currently using, and it probably doesn't have any errors. <jab>or else your computer probably would boot... ***sneek_ is now known as sneek
<Guest36>omg somehow one parentheses moved forward by a unit <Guest36>I had no idea that would cause such a cryptic error. Thank you so much :))) <Guest36>has anyone gotten emacs-exwm to work with emacs-native-comp? ***Guest36 is now known as LemonBreezes
***srk_ is now known as srk
***srk_ is now known as srk
<calnombl>hey so, I just tried to guix system init a pinebook pro <calnombl>and, I need help? I can't exactly copy/paste a log but I can attempt to type stuff out if that'd be helpful <calnombl>currently it boots to initrd, successfully decrypts and checks the rootfs, and then says "error in finalization thread: Success" and all services promptly declare they have failed to start <calnombl>ie, file-systems, user-homes, term-tty*, etc <muradm>there was an extra wierd syntax for inserting '() into gexp output <muradm>currently (define exp1 '()) and use #~(begin exp1) unwinds to (begin ()) which is not correct <muradm>what should be in exp1 to acquire (begin '()) <muradm>and this seems to work (define exp1 '(quote ())) <wdkrnls>Dear guix, why I can no longer start emacs from a shepherd service? <wdkrnls>error: connect: /run/user/1000/shepherd/socket: No such file or directory <wdkrnls>That error appears whenever I run any herd command. <wdkrnls>If I call shepherd directly, then I see a note about my "emacs" service starting. However, I cannot seem to be able to access it via emacsclient. <wdkrnls>Yet, when I try to make a new server with a manually started emacs, that one complains there is already a server running :/ <Gooberpatrol66>so shepherd user services are specified in $HOME/.config/shepherd/init.scm? what's the simplest way to specify them in config.scm? <muradm>Gooberpatrol66: you mean like in main (operating-system ..) config? <podiki[m]>I've also been wondering about user services <podiki[m]>by default does shepard run the ones in $XDG_CONFIG_DIR/shepherd/init.scm (or does that need to be activated in system config)? <muradm>podiki[m]: you can specify custom config with "--config" option probably, depends on what you want to do with user services <podiki[m]>similar to systemd user services, just some background programs that should run <podiki[m]>and is there any builtin hook to syslog? or should logger be specified somewhere in what to run? <muradm>i don't use system config to define them, i start it from .bashrc on login, then it fires up everything i defined under ~/.config/shepherd/ <muradm>no idea about syslog, there is "--logfile" option at least :) <podiki[m]>I like to keep a terminal open that shows /var/log/messages, so it's nice to have background processes log there <podiki[m]>what I meant earlier was if the system config can activate shepherd user services? but I guess that is tied to a user login, so maybe doesn't make sense <muradm>podiki[m]: i think you have to wait guix home stuff <muradm>with my way, of course system config is not aware of what im running <muradm>with guix home, i have no idea, not interested in that.. :) <podiki[m]>in the end not different really from some startup programs really, so makes sense to have them as part of login <podiki[m]>I just want to get the output and easily stop/restart, so shepherd looks good <muradm>for something like starting user services while user is not even logged in is something weird <muradm>if you need, you can run separate shepherd for every program :D <muradm>to control that program with simple stop start :D <muradm>that depends on what program(s) you want to run <podiki[m]>don't think I'll need that, right now it is for stuff that only makes sense when logged in <podiki[m]>(one a little go program that changes light/dark themes based on time, the other for watching for imap events to get mail notifications) <muradm>if you use sway/i3 that should be pretty simple in their configs <podiki[m]>I'm on xmonad currently. running them isn't a problem, just want to have easy control and output, figure it's time to give shepherd a go (had finally got around to some systemd and now moved to guix :-P) <podiki[m]>looks similar to what mine probably is! mu, redshift, dunst, pulse, some shells and terminals, emacs... <muradm>basically .bashrc starts shepherd and then it starts pretty everything else <podiki[m]>yup, a few things in some zsh files and then some in xmonad's config, a couple xdg autostarts (run by dex), in my case <muradm>which is not very easy to workaround <Gooberpatrol66>pulseaudio appears to be running under my user account instead of root. how is that done? <muradm>podiki[m]: relatively easy to manage, clean and tidy, taste may be also :) any thing wrong with it? <podiki[m]>just curious! I like consolidating and making things minimal too <muradm>yes minimal is another thing, should be light 400-500mb ram on first login <muradm>also portable, i can run 2 3 independent of these on different ttys <muradm>with one exception gpg-agent, which can't solve at the moment <muradm>no icons, no buttons, just borring terminals, emacs frames and browsers :D <muradm>i like haskell and tried xmonad once, i didn't find it very minimalistic.. pulling in that haskell infrastructure is like inviting elphant to the room :D <muradm>letting it stay in another guix profile <podiki[m]>I like stump too, but ran into a bug with plugging in another display, which I rarely do but still <podiki[m]>maybe I should go back, lisp over haskell for me <ennoausberlin>Hello. I host a guix instance on a virtual root server. I wonder how I can configure remote access with GUI. Normal ssh works. ssh -X does not forward. rdp gives me pam authentification error. vnc also fails. Have you a working setup lying around? <qzdlns[m]>ennoausberlin: what do you mean by 'ssh -X does not forward' ? <ennoausberlin>gzdlns[m]: I am not sure if I exposing too much information with -vvv on pastebin <qzdlns[m]>okay I get that, do you see any error lines? anything talking about auth? <ennoausberlin>if I start xev on remote I get xev: unable to open display '' <qzdlns[m]>I can see from those logs that you're spoofing auth <qzdlns[m]>and environment variable $DISPLAY is exported? <ennoausberlin>Hmm.. where do I set this? And what value is needed? export DISPLAY=:0 ? <qzdlns[m]>it's how one identifies X servers and X displays <qzdlns[m]>export DISPLAY=:0 is probably okay in most simple cases <ennoausberlin>I usually work on console and this X stuff is almost new to me. On widespread distros this already configured <qzdlns[m]>yeah it really depends on how X has been configured - on mainline distros when you're shipped a WM or DE, then you're implicitly shipped a some sort of config <ennoausberlin>I tried to put the DISPLAY export into /etc/sshrc and herd restart sshd but the display is still '' <qzdlns[m]>for reference, you can locally set DISPLAY for the command by using <ennoausberlin>I tried on the remote machine DISPLAY=:0 ssh -X localhost and I got <ennoausberlin>Warning: untrusted X11 forwarding setup failed: xauth key data not generated <qzdlns[m]>honestly I'm not sure where this DISPLAY var 'should' be exported - if at all when running in a console session - can't find any docu for this <qzdlns[m]>have you reset sshd since you changed your config? <ennoausberlin>Usually it is created if you just run xauth but it does not. I try to create it manually <ennoausberlin>zdlns[m]: I have remote gui access via web interface to guix. The hoster provides this. If I open an xterm I can see that $DISPLAY is set to :1 <qzdlns[m]>are you getting the same problems with `DISPLAY=:1 ssh -X -v 1.2.3.4` <civodul>PurpleSym: i was planning to merge master into core-updates-frozen today (if nobody else did) <civodul>PurpleSym: did you apply these patches (ocl-icd) to master? <PurpleSym>civodul: Yeah, I originally pushed them to master. ***o is now known as niko
<ennoausberlin>If I run xauth on the web console he prints that he uses /run/user/1000/gdm/Xauthority <ennoausberlin>So I symlinked $HOME/.Xauthority to this file and after DISPLAY=:1 xev after ssh -X it starts xev <moshy>hi guix. i noticed the newest linux-libre became available, however it didn't automatically upgrade from 5.13 and instead updated to 5.13.14-gnu1. can specific versions be declared in config.scm? <ennoausberlin>qzdlns[m]: Call me stupid: On my local machine runs wayland. I was not aware of this. I am pretty sure X forwarding is not part of wayland <roelj>Question for anyone willing to try: Does the memory usage increase over time for you as well when running this in a "guix environment --ad-hoc guile gnutls": http://paste.debian.net/1210727/ ? ***raspbeguy is now known as guy
***guy is now known as raspbeguy
***raspbeguy is now known as guy
***guy is now known as raspbeguy
*civodul drowns in merge conflicts ***raspbeguy is now known as guy
***guy is now known as raspbeguy
***raspbeguy is now known as guy
***guy is now known as raspbeguy
***raspbeguy is now known as guy
***guy is now known as raspbeguy
***raspbeguy is now known as guy
***guy is now known as raspbeguy
<civodul>roelj: hi! memory usage seems stable for me <ennoausberlin>Both machines now run Xorg, but still X11 forwarding request failed on channel 0 <qzdlns[m]>is the verbose output the same? about xauth? <ennoausberlin>I can easily use forwarding on my second machine running debian 10 <ennoausberlin>debug1: Requesting X11 forwarding with authentication spoofing. <moshy>MysteriousSilver: Looked into it and I found i had to simply declare (kernel linux-libre-5.14) under operating-system, then add (gnu packages linux) to modules, to successfully upgrade to 5.14.x <moshy>Wondering if I can use something like linux-libre-latest to always point to the latest stable version <MysteriousSilver>moshy: sometimes the definition of 5.14 might be removed as it becomes older, thus it becomes necessary to specify the commit. as for pointing to latest stable version, i have no idea (i manually increment versions) <moshy>MysteriousSilver: I see. I'm guessing it behaves in such a way that, after 5.13 becomes EoL, then it automatically switches to 5.14 <ennoausberlin>It would be nice if someone can confirm he had ssh -X working on his guix machine <civodul>ennoausberlin: "ssh -X" definitely works for me <civodul>ssh from Guix does not refer to /usr/bin/xauth <ennoausberlin>civodul: Can you start a remote app and view it on your local desktop then? <roelj>civodul: Thanks for running it :) <civodul>ennoausberlin: actually i don't have an example that works now, though i think i used it <liltechdude>Hello guix! I am looking for articles with theme something like `Moving from simple Dockerfile to Guix Container`. Have you something like this? <liltechdude>All articles that I found was about `How to run docker on guix` <qzdlns[m]>ennoausberlin: did you look into your xauth configuration? and to clarify, are you running from guix<->guix, or is the 'remote' (the server) only running guix? in any case, you will need to ensure your xauth on both machines are properly configured <ennoausberlin>qzdlns[m]: local machine is an Ubuntu 21.04 - remote is full updated GUIX. <qzdlns[m]>cool, and you have entries on that remote machine when you run =xauth list= ? <ennoausberlin>I can remote ssh -X from my local Ubuntu machine to a third debian 10 machine and ssh with X forwarding is working. <qzdlns[m]>and=ssh -Y= to that remote gives you an error or a warning? <qzdlns[m]>the warning may look like "Warning: No xauth data; using fake authentication data for X11 forwarding.", which is insecure, but functional (test as you have with xev) <ennoausberlin>xauth list gives me 2 lines - one starting with guix13/unix: and another starting with #ffff# <ennoausberlin>ssh -Y gives me X11 forwarding request failed on channel 0 too <ennoausberlin>debug1: Requesting X11 forwarding with authentication spoofing. <qzdlns[m]>is there anything is your syslog on the remote about this? <qzdlns[m]>the spoof suggests your xauth for that user isn't being hit <ennoausberlin>unfortunately guix does not write special sshd logs. /var/log/messages, /var/log/debug and /var/log/secure does not give any hints <ennoausberlin>It already costs me hours to find a solution. What about tigervnc-server, xrdp or spice. Is there a guix tutorial for this? <dhruvin>How much time is normal for "guix pull" to run for the first time on a freshly booted (run on 2 core 4gb ram) qemu vm? <dhruvin>context: I'm building a build image for sourcehut and it takes several minutes to run guix pull for build user (the first time). <dhruvin>Followup question: the images will be built nightly. the system profile will be *almost* up to date. Is there a way to minimize the time taken bby "guix pull" by somehow using the system's profile? <maximed>dhruvin: channel-with-substitutes-available <maximed>That way, it will use the latest guix for which substitutes are available on ci.guix.gnu.org <maximed>(this does not imply substitutes are available for all packages of that guix) <dhruvin>maximed: An update, as of now sr.ht has no plans on setting up a proxy cache server you talked about yesterday. It may be on the table once builds.sr.ht gets its overhaul update. <maximed>dhruvin: Was this discussed with sr.ht on some public location? If so, could I have a link? <dhruvin>maximed: It was on #sr.ht on libera chat. I'm not sure if they have logs like we do. <civodul>are we doing something in Python that sets dont_write_bytecode = False? *civodul is almost done merging master in core-updates-frozen <civodul>the "interesting" thing is that it triggers a rather big rebuild <civodul>because librsvg on core-updates depends on lotta rust things <qzdlns[m]>is anybody using EXWM as a drop-in desktop entry? looking to chuck out my xinitrc <civodul>qzdlns[m]: i start it via ~/.xsession <civodul>but it should work via a desktop entry <civodul>(you can check in a "guix system vm" VM) <civodul>master -> core-updates-frozen merge done! <civodul>i'd appreciate feedback, in case i broke things <civodul>there were lots of conflicts to solve in python-xyz.scm and check.scm in particular <qzdlns[m]>man I should have tried system vm earlier, this whole time I've been nuking my system 9/10 times for config changes <ekaitz>hey roptat: I just found your guix-android project, is there anything I can do for help? <muradm>civodul: by checking you mean compile and test? :) rebuilding the world does not look like option.. <civodul>muradm: taking a look at the diff of the merge commit, checking whether your favorite packages still build (no world rebuild involved) <muradm>hmm.. if meson-configuration.scm is new core-frozen-updates, could be leftover from branch switches <maximed>(core-updates actually, before the -frozen was branched off) <xd1le>newbie question, the way I understand it from reading the manual, it's 'safe' (in terms of world rebuilding/substitute availability) to guix pull the master branch, right? <xd1le>i.e. the world rebuilding changes go first to staging/core-updates ? <maximed>Though master does not always have substitutes for everything <maximed>it should have substitutes for most things though <dhruvin>maximed: I used what you suggested. I understand that it'll help when ci doesn't have packages built for definitions in latest commmit of guix. Follw-up question: It will still perform "git clone/pull <guix repo>" (I saw some 1800 commits received), right? <maximed>dhruvin: 'channel-with-substitutes-available' only verifies a substitute for guix itself is available <maximed>it doesn't check substitutes for packages defined in that guix are available <maximed>I suppose it will still run "git pull" <dhruvin>maximed: I believe when we create a system image, it should include the guix checkout it was built with. Correct me if I'm wrong here. Can't we just use that somehow? Since it'd be already pulled and authenticated. <maximed>the guix the system image was created with is newer than the guix inside the system image (until the next guix pull) <maximed>guix does have a package definition of itself, but it's not updated regularily <maximed>only when there are changes to the daemon, when guix-cuirass needs a newer guix, before a release <maximed>It would be possible to adjust the definition of the system image such that it includes a guix with the same commit as the guix that the system image was created with I suppose <maximed>Maybe a minimal system image for CI systems could be created, that uses the latest guix? <dhruvin>maximed: I'm sorry. I got disconnected. Did you post anything about it? <muradm>civodul, pending patches applied straight and built with no issue, tests required librsvg recompile you mentioned... :) <dhruvin>maximed: Okay. I can give that a shot. I will let you know if I manage to create an image with latest guix packaged with it. <muradm>uh oh.. core-updates-frozen running "make check-system TESTS="my-test"" starts deblobing 5.13.13.. would be painful if it will build it.. <raghavgururajan>maximed and lilyp: I was wondering if you are available to help me with review of forthcoming patch-sets of gnome work? :) <lilyp>Currently working on a hacky mail client, but I'll look at them if I have some spare time <maximed>raghavgururajan: I'm available for the ‘this patch lgtm but I didn't test this’ and ‘keep in mind that ...’ kind of reviewing <civodul>looks like "guix refresh" will soon support Git repos both as a source of info and as a way to fetch code \o/ <muradm>and it is compiling 5.13.13 kernel after deblobing... <muradm>that will take another 2-3 hours.. :) <civodul>(though "howdy" is more like "hi" if i'm not mistaken :-)) <roptat>mh, thought it was a contraction for how do you do or something ^^' <civodul>roptat: did you have a chance to look into those icedtea C++ monstrosities? <roptat>yeah, I have a few fixes but it's not enough... I was able to build icedtea@1 by adding ("gcc" ,gcc-7) to the native inputs though <roptat>do you think it's a good solution? <civodul>a build flag may be more future-proof though <roptat>well, what I have is one patch and a few substitutes to the various sources of icedtea... it's not elegant ^^' <abrenon>what was wrong with icedtea ? (I may have to package java applications…) <ekaitz>hey roptat: i pinged you before but you weren't here, do you need some help with guix-android? anything I can do? <roptat>abrenon, it doesn't build on core-updates-frozen <roptat>ekaitz, yes! I'd need help figuring out how to cross-compile libcxx and libcxxabi (from (android packages clang)) <ekaitz>aiight! I'll try to take a look to it (but I won't promise anything!) <roptat>I noticed that libcxx gets a gcc native-inputs and a cross-gcc input, but even removing both entries from CPLUS_INCLUDE_PATH doesn't work, it looks like it can't find the correct headers and still defaults to gcc's headers that won't work with clang/llvm <roptat>I know CPLUS_INCLUDE_PATH is not in the same order as in a native build, but I'm not sure how it can influence the build <abrenon>oh, I see, so that's quite out of my scope, luckily for me <ekaitz>roptat: doesn't GCC use CROSS_WHATEVA_PATH and stuff like that? <ekaitz>i speaking from memory, which is not very reliable in my case <roptat>I remember something similar too, though not the details <civodul>zimoun: ah yes, i'll take a look soonish, i'm already lagging behind... <civodul>(but hey, i recently applied 8-month old patches!) <zimoun>civodul: yeah! post-holidays syndroma ;-) That’s just because I had some headache about the transformations and I would like to “transform” the try (rugby metaphora ;-)) <civodul>i sympathize: i inflicted myself a few headaches on this topic in the past <muradm>i ran make check-system TESTS="my-test", it started building kernel and then failed on glibc <civodul>i'll take a look if nobody beats me at it <muradm>civodul: also that kernel build thing, does it related to changes regarding teardown of libre-kernel etc.? <muradm>a lot of packages downloaded as is, but kernel is rebuilding <dhruvin>Why doesn't guix package itself (instead of an older version) with the system image it creates when run "guix system image ..."? <dhruvin>Is it by design? or am I missing something important? <maximed>dhruvin: because that's more difficult. Using the older version is simpler <maximed>also, it would make ./pre-inst-env guix system image ... take longer <maximed>it might be a good idea to change this <maximed>dhruvin: Did writing a definition for a guix system image that includes the guix that it was being built with work? <dhruvin>For (current-guix) I'll need to git pull guix repo -> [env] -> ./bootstrap -> ./configure -> make -> ./pre-inst-env guix system image ...? <maximed>dhruvin: no, "guix system image .... the-configuration.scm" should work I think <dhruvin>I tried two things. First use system guix (after guix pull). It failed at some stage (mktemp! error). I can lookup that error in a minute. <dhruvin>Second, the repo way, which had failing tests when ./pre-inst-env guix system image ... (while building guix-1.3.0-xxxx+.drv <civodul>muradm: i suppose it's just that the kernel hasn't yet been built for that branch <maximed>dhruvin: Can you paste the error (paste.debian.net) <dhruvin>maximed: It has two parts. 1. First guix image from foreign distro (most likely arch/alpine), then 2. Subsequent guix images from the first guix image. <dhruvin>maximed: First image is built using official guix-install.sh on a foreign distro <dhruvin>maximed: Subsequent images are created after a guix pull on existing guix image <dhruvin>maximed: I'll share the errors along with the image build script and a system.scm. ***sneek_ is now known as sneek
<lispmacs[work]>what were the --ad-hoc tools needed to build guix? there is coreutils, make, and something else... <dstolfa>(nix-daemon is c++, guix is... well, guile) <maximed>lispmacs: "guix environment guix" --- no need for --ad-hoc <lispmacs[work]>maximed: in the video, the command was "guix environment --pure guix --ad-hoc coreutils..." <dhruvin>maximed: I just added (current-guix) from (gnu packages package-management) to packages field of <operating-system> <dstolfa>ah, you don't actually need that lispmacs[work]. you can just do as maximed said <maximed>dhruvin: (about system.scm) Seems reasonable, though I have never done something like that <maximed>the script for generating the image seems reasonable, except for the "curl STUFF | bash -". You're relying on TLS for security here <maximed>but if it's only for the initial image, maybe that's acceptable? <dhruvin>maximed: Yes, it's only for the first image. <maximed>(cons* %default-channels-with-...) can be simplified to %default-channels-with-... <dhruvin>maximed: It'll be updated with additional channels users will provide. See actions section. <maximed>You might want to verify that the OpenSSH configuration is secure <maximed>as it is now, it looks like anyone can ssh to the builder and gt root access <dhruvin>maximed: Yes, that's intended. They (ports) are never exposed publicly. <dhruvin>maximed: I will ask sr.ht about it. (Rest of their images do this as well.) <dhruvin>maximed: *rest of their distos do this as well. <dhruvin>maximed: In (current-guix) the mkstemp! error comes from 'disable-failing-tests' phase. I faced similar issue when I "substitute* <a-missing-file>". Any ideas on that? <utis>can any of the binaries be used on armv7l (raspberry pi)? ***sneek_ is now known as sneek
<maximed>dhruvin: Could I see a (build?) log with some context? <roptat>utis, I think that's what we call armhf <maximed>the /var/log/....drv.bz2 will have more details <maximed>Curious, everything under "tests" does not exist <attila_lendvai>is there a simpler way to try a new package in the environment of my user? what i do currently, but takes too long: git commit the change, guix pull from my guix repo checkout, then guix package -u <dhruvin>attila_lendvai: Did you try the ./pre-inst-env way? <attila_lendvai>dhruvin, hrm... apparently i'm still lacking a mental model of that ./pre-inst-env... lemme try <dhruvin>attila_lendvai: guix environment guix -> ./bootstrap -> ./configure --localstatedir=/var -> make -> ./pre-inst-env guix environment --ad-hoc your-package <dhruvin>attila_lendvai: (assuming you're using guix while building a guix package) <attila_lendvai>`./pre-inst-env guix package -u` does exactly what i want... thank you dhruvin! <attila_lendvai>dhruvin, i was already doing the beginning of those incantations, but i failed to connect the dots that i can just guix package -u from there <dhruvin>attila_lendvai: I prefer using ad-hoc environments (for packages that I am building) instead of installing packages in my user profile. <dhruvin>attila_lendvai: "incantations", haha. <attila_lendvai>dhruvin, this is trezor-gpg-pinentry-tk, a pinentry app for gnupg. i assume that i need to install it, or at least it's wiser to have one fewer source of issues <dhruvin>attila_lendvai: I guess yes. I never build a package like yours. <maximed>dhruvin: Maybe the scheme equivalent of "guix build guix --with-commit=guix=THE-COMMIT"? <maximed>Were "THE-COMMIT" is determined with the Scheme equivalent of "guix describe"? <dhruvin>maximed: Are you suggesting that I should try "guix build guix --with-commit=guix=3d42aa33da54e9a289112afc4ad4662b9402b2f4"? <maximed>maybe something like that could be done from within the system configuration instead of (current-guix) <maximed>since (current-guix) doesn't work from a guix build with "guix pull"? <dhruvin>maximed: (current-guix) doesn't weok from ./pre-inst-env either. It has failing tests. Should I send logs? <maximed>dhruvin: it should work from ./pre-inst-env I think, so yes, please do <dhruvin>maximed: (I hope I'm not asking for too much help.) ***sneek_ is now known as sneek
<iskarian>civodul, thanks for doing the thankless work of merging! <moshy>I wonder how one could actually rebuild the world locally. tried guix gc, then guix pull --no-substitutes. seems to go fine, until the build gives an error about not being able to run perl <iskarian>looks like we've got a lot of rust packages failing now in core-updates-frozen <raghavgururajan>sneek, later tell nckx: [1] I would like your advice in something. In non-master branches, if an update to a package break its dependants, should the dependants be fixed on same commit or different ones? <iskarian>a lot of "error: failed to prepare local package for uploading <raghavgururajan>sneek, later tell nckx: [2] Also, if fixing the dependants is a quite a line-of-work on its own, can it be delayed till the end of the intial work? <iskarian>Looks like most of it is due to rust not finding dependencies (sometimes it finds them, but they're the wrong version) <iskarian>The rest seems to be that the compiler was updated and some packages no longer build because of deprecated syntax, etc. <muradm>civodul, that glibc thing will be resolved on core-updates-frozen, right? :) ***sneek_ is now known as sneek
<sneek_>Welcome back nckx, you have 2 messages! <sneek_>nckx, raghavgururajan says: [1] I would like your advice in something. In non-master branches, if an update to a package break its dependants, should the dependants be fixed on same commit or different ones? <sneek_>nckx, raghavgururajan says: [2] Also, if fixing the dependants is a quite a line-of-work on its own, can it be delayed till the end of the intial work? ***sneek_ is now known as sneek
<maximed>it's not giving an error about perl, it's a warning and probably harmless. The issue seems to be from 'stat'. <maximed>I think I've seen faimiliar issues before on the bug tracker <moshy>yeah it's missing the makefile and there's no config <nckx>raghavgururajan: [1] If the ‘fix’ doesn't break building against the old version, apply the fix first, then update the package in question. If it does break, it's not much of a fix^W^W^W^W^W^W include the ‘fix’ in the same commit as the update. The goal is to keep commits limited to only one logical change and never to introduce a regression between commits pushed together. If those 2 are incompatible the latter one wins. <iskarian>Can "guix weather" take a glob? (What I'm actually trying to do is: get a list of failed cuirass builds matching a glob) <nckx>[2] Not on master, no. ‘We updated libfoo, now 23 packages are broken but we'll fix them later’ happens, but should not be done on purpose. <nckx>On a wip- branch, of course, go nuts. <nckx>iskarian: No, but extending it to support REGEX instead of PACKAGES (please, no globs!) sounds like a worthwile goal? <nckx>If I'm not clear, ping me raghavgururajan, I'm a bit distracted 😉 <iskarian>Sure, regexes are better. That sounds nice. I don't think I'll pick it up myself, I can probably just `guix search | recsel | xargs guix weather' for now <nckx>Yeah, that's what I'd do TBH, but ‘guix foo REGEX’ is a well-established pattern by now. <dhruvin>maximed: both ./pre-inst-env guix ... and guix --with-commit are failing <dhruvin>maximed: I'm sharing logs of both in a minute. <sneek>lfam, dstolfa says: my download's done, i have 300G of stuff now (compressed) and can serve it if needed for a download <lfam>sneek: later tell dstolfa: Thanks! I think we are still waiting for some clarification on what is going to happen next... <attila_lendvai>so, the python app called trezor-agent (actually its libagent) uses sys.argv[0] for something, but on Guix the wrapper script calls the renamed original file, which changes sys.argv[0] and breaks the app. what shall i do? report this as an issue? <attila_lendvai>it works on nixos. python is packaged differently there and it doesn't interfere. <lfam>I don't have an answer but we must have encountered this issue before. There are a huge number of wrapped packages *attila_lendvai searches the issue tracker <lfam>I'm used to seeing annoying program output like ".borg-real did foo" <lfam>Maybe parsing argv[0] is a little too clever but we should still make sure it works <moshy>more failed builds discovered, all with the mesboot suffix: sed, diffutils, patch and bash <moshy>after attempting the guix pull build, with --keep-going <lfam>Going back to your earlier question about kernel upgrades moshy, I can confirm that 5.14 is not yet the "default" kernel package <lfam>I usually preserve the older stable kernel as the default until it stops being supported upstream, to ease the transition to new versions <moshy>Yep, actually saw that earlier in the file linked, still set on 5.13. think it's a sane default, to give time beforehand <lfam>Yeah, there are usually some bugs in the early releases of a new series, so this makes it easy to wait them out <lfam>moshy: So now you are having trouble with something else? `guix pull` fails? <muradm>lfam: how are you? :) sorry bothering about #49969, i think i'm ready to put sway greeters as well with update sway 1.6 to sway 1.6.1.. :) <lfam>I'm okay, just barely keeping up with everything I need to do right now <lfam>I'm moving to another city this month so I'm pretty busy <lfam>I will get around to a final review of the seetd / greatd patches though <moshy>lfam: doing a fresh build on my machine, using --no-substitutes, to see if it works in practice. the binaries are all fine and well atm <lfam>If you have more trouble, the best way to share details is to share the results of `guix describe`, the exact command that you ran, and any logs mentioned in the failed build errors <lfam>And also what type of CPU platform you are using (x86_64, i686, armhf, aarch64, etc) <lfam>That makes it possible for other people to easily test for the bug <moshy>really just used guix gc, then guix pull --no-substitutes. I've got 4 extra log files for failed builds <lfam>moshy: In order to attempt to reproduce the problem, we still need `guix describe`. Otherwise we don't know how to reproduce your build environment <moshy>would this be the right output? <lfam>Okay, so people using x86_64 could do `guix pull --commit=3d42aa33da54e9a289112afc4ad4662b9402b2f4 && guix gc && guix pull --no-substitutes` and come close to approximating what you are trying <lfam>The main difference being what may or may not be garbage collected <moshy>i cleared all my previous generations before doing so as well <lfam>Yeah, that helps with the GC <lfam>Many of us are not going to want to do that <moshy>although i can assume it'll still redownload and rebuild stuff <lfam>If something is already in /gnu/store, it will be re-used and not built <nckx>Then it's fine, the danger is in documenting/remembering/not forgetting/vaguely recalling what all's broken so it doesn't get merged with forgotten bugs. <raghavgururajan>Cool! Is there a way to build all the dependants of a package, in a single command? <nckx>Single no, but something like ‘guix build $(guix refresh -l package | cut -d: -f2-)’ should do that <nckx>Protip: add --keep-going if that's a pre-bedtime command. <iskarian>nckx, I don't have a repro handy but I've definitely had --keep-going not keep going before <iskarian>IIRC, it was when I specified both a package and its dependency, the dep failed to build and it kept going, but when it got to the other package it bailed *raghavgururajan almost got burned by the VGA slot, near the CPU. ♨️ <vats>Hello, does anybody have ideas about using Freenet on GuixSD? It requires gradle to compile which hasn't been packaged yet. Perhaps ArneBab has something to share from his setup? (Being a freenet developer who also uses guix.) <moshy>I'm gonna try an alternate method to reproduce the build error, using a clean, minimal Guix 1.3 install in QEMU. TinyCC currently in progress <nckx>iskarian: Huh. Leaving others unbuilt? <nckx>raghavgururajan: That sounds normal and healthy. <iskarian>nckx, Yes. I encountered this when I was rebuilding all Go packages. <nckx>Got to love the old-school thinkpads with their antifreeze ports. <iskarian>If I encounter it again I'll try to send a proper report <nckx>And you're positive that Guix could have continued? If you can provide a reproducer it might be worth investigating. <iskarian>I'm sure it could have, because I re-ran the command unchanged and it would start building other packages. <nckx>That is an acceptable level of certainty. <iskarian>Ah, thanks :) if I find a repro I'll just reopen that bujg <civodul>iskarian, maximed: just sent a proposal for 'package-definition-location', inspired by maximed's <civodul>iskarian: just replied and in short, rebuilding gnu/packages/*.go should save you :-) <iskarian>thanks. currently rebuilding, I'll let you know if it works <iskarian>civodul, that fixed it. I went ahead and closed the issue <lfam>voroskoi[m]: Hm, looks like a spurious build failure indeed <lfam>And that package is low low in the dependency graph so it represents a big problem for users <lfam>So, if you haven't already, you might also enable substitute fetching from bordeaux.guix.gnu.org <lfam>It might not suffer from this issue <lfam>It's enabled by default but that's a recent change so older installations might not be using it <iskarian>There are also still a number of packages which haven't be (re-)built due to "missing derivation" errors <lfam>Yeah, that's another issue on CI that caused many spurious failures <lfam>I'm not sure I've seen this "empty status" error before, although there are a few hits in my mailing list archives <lfam>It would be great to figure out if this problem is unique and unreported. And if it is, to make a bug report :) <lfam>It's weird but that libxml2 derivation is actually built on ci.guix.gnu.org <lfam>(Maybe somebody else rebuilt the derivation "by hand" on the server. It works but it's not reflected in the web interface) <lfam>And the other source derivations mentioned in the log are also built <lfam>Now that many of the Cuirass bugs are fixed, it's probably time to stop building things by hand on the server <lfam>The cost in terms of UX on the web site is pretty high <lfam>That link is in case you need an example of targeted queries <lfam>We need to update the example to change from 'guix-master <lfam>From 'guix-master' to 'master' <lfam>That's in cuirass.git, if anyone wants to land a patch :) <ArneBab>sneek later tell vats I use ./gradlew in guix which works. <voroskoi[m]>the manual build does not solve the issue with builds does not even starting because of missing deps, does it? <lfam>voroskoi[m]: No, and that's another reason not to do it <iskarian>Oh boy, about to do a pull on a month-old guix ***duds-_ is now known as duds-
<blackbeard>iskarian: you'll be fine. I recently did one in like a 3 months old <lilyp>don't do numbered thingies in patches :P <lilyp>otherwise "lgtm, but haven't tested" <iskarian>raghavgururajan, I believe lily means "PATCH 2/2" etc. <iskarian>Subject: [PATCH 2/2] Names of libraries included in typelib files are opened ***duds-_ is now known as duds-