IRC channel logs
2024-10-21.log
back to list of logs
<[>Why are the arm-none-eabi toolchains functions rather than normal packages? <[>It means that there's no substitutes, and compiling them takes ages <fnat>What do I need to restart to have my '/run/user/1000/shepherd/socket' file recreated after I messed things up? <Hamled>unmatched-paren: just came across an bug-guix email thread about using wlgreet with seatd in which you mentioned that you never had to do anything to create the XDG_RUNTIME_DIR directory for the greeter user... did you ever figure out why that was? <marmalade>How can I set up Guix on a foreign system such that GUI apps set themselves up properly, like populating in the app list, etc. etc.? <zamfofex>marmalade: Is there anything that doesn’t work except for them not showing up in the “app lists”? That should be fixable by setting up a link or env variable to the directory on your profile with the ‘.desktop’ files. <marmalade>zamfofex: no actually minus like, following my icon theme <reepca>I can't seem to get the gpgme-1.23.2.tar.bz2 download to work, it first 404s on the artfiles.org site and then tries the crysys.hu mirror, which gives an html page that turns into an error page once javascript is interpreted, which naturally is a hash mismatch. <reepca>I wonder if it would be good to have the downloader check the hash itself and keep trying mirrors until it gets the right one <reepca>there are 18 mirrors for gnupg listed in %mirrors, and all of them after the second don't accomplish anything because the second one causes a hash mismatch currently <podiki>blog post/email announcement to follow (hopefully within a day) <efraim>sneek: later ask vagrantc do you happen to know why mesa on aarch64/armhf wants libarchive and lua? I haven't really tested it much but when building I'm not seeing a difference between including them and not <nckhexen>fnat: I vote for OTOH, if you have the time. <civodul>blog post by reepca will be on-line in a few minutes (hopefully) <Rutherther>civodul if I understand correctly, that means during any build that would make setuid/gid binary this can be exploited is that so? <Rutherther>And if one used keep failed, then it would be exploitable even afterwards <civodul>Rutherther: it’s even without --keep-failed <ekaitz>civodul: guix pull should fix it right? <civodul>ekaitz: check out the instructions in the blog post above or in ‘guix pull --news’ :-) <fnat>nckhexen: Yeah I also think so, I'll report my findings/issue later today. Thanks! <civodul>trofi: hi! there are discussions to make a release, but that won’t happen before some time i’m afraid <trofi>Aha, sounds good. Thank you! <futurile>trofi: you can use the latest iso image off the site if you don't want a big guix pull <ekaitz>hi is it possible to disable tests from an inferior? <ekaitz>i'm trying inheriting it, also with transformations... and I don't know how to do it <futurile>ekaitz: guix build <whatever> --with-tests=package ?? or you want the way to do it in code <futurile>ekaitz: you can't just do #:tests? #f - that doesn't work - *confusing* <ekaitz>i can't inherit an inferior as a package <Rutherther>civodul without keep failed after the build is finished? <trofi>futurile: i package `guix` as a package built from source for a foreign distribution. it's a bit nicer to have a baseline everyone can use as the same base. <efraim>ekaitz: there's a qemu-7.2.4 in guix, and it has tests disabled <apteryx>efraim: uh; all tests disabled because ";migration tests still fail". seems we could have disabled just those <sneek>Welcome back apteryx, you have 1 message! <sneek>apteryx, lilyp says: I need to hold off the glib change, because python-pygobject and gjs break – updating pygobject is no biggie, but gjs requires a newer mozjs (128 as of the latest version) <apteryx>lilyp: I noticed that too; I had updated python-pygobject on my side as well <apteryx>also, the glib with documentation was broken, that's fixed on my local branch too <apteryx>efraim: ah at least qemu 7 is the past, not the future (we're now on version 8) <apteryx>hm, gdb appears broken for me while stepping a C++ program: Python Exception <class 'AttributeError'>: 'NoneType' object has no attribute 'pointer' <ekaitz>efraim: but is that the one i need? <ekaitz>now I need to recheck why I used an inferior instead <efraim>it's the one I use on my x86_64 machine to build riscv64 packages when I don't feel like waiting for the offload <efraim>so I would assume so, since I learned about it from you <ekaitz>haha so you added it back in? if i'm not mistaken it was removed from guix in the past <apteryx>to workaround this python bug with gdb, I disabled python support in GDB, like so: guix build --with-configure-flag=gdb=--without-python gdb <efraim>oh man, %boot0-inputs has double of most packages on i686 and x86_64 <efraim>environment variable `PATH' set to `/gnu/store/kpvjkrb74hrnx2yvwxd570nq3yxkg9z8-bzip2-boot0-1.0.8/bin:/gnu/store/swj0cmz1xy6xya9hy2rp089mp4wch1vl-coreutils-boot0-9.1/bin:/gnu/store/sx98j64cc1fqlby5r2f2bwnz67a06388-gawk-boot0-5.3.0/bin:/gnu/store/a8x54d3qlj2s8pdngbclm06la8kl99n2-patch-boot0-2.7.6/bin:/gnu/store/dpw1y93cimr9wp0jcb9kvpnn7z31gf9p-sed-boot0-4.8/bin:/gnu/store/dx4zy2c7xi0pvpgpy2xx2qd3glp59qbk-tar-boot0-1.34/bin:/gnu/store/ <efraim>m0dl1b2cq34j6v5p6vgl6l6481rjnlih-make-boot0-4.4.1/bin:/gnu/store/r0l7v0yjn8rf8imlvhm4cxv7py1kyqi6-diffutils-boot0-3.10/bin:/gnu/store/5apcc6dp2d8aik9airxchw5fvnfxkn7z-findutils-boot0-4.9.0/bin:/gnu/store/5vn8zannclfgp4jsix9v4cx3sjnk54db-file-boot0-5.45/bin:/gnu/store/k91vpkvmpz7fffsin4w3r5m9wfx7w79q-bash-mesboot-5.1.16/bin:/gnu/store/6z9rcm68lf2xzjaq1qq7r8fc4qaicvnk-coreutils-mesboot-9.1/bin:/gnu/store/b2z758sp6sz5liz910q1dahcsca9wh34-grep-mesboot-3.11/bin:/ <efraim>gnu/store/yvz3cfyl4c2s7ljscnkn1hwjm03sqly3-sed-mesboot-4.8/bin:/gnu/store/5vnfs68rfwishrxmp24wgp26csnnqigh-tar-mesboot-1.34/bin:/gnu/store/39467chq67qp2km1wfad5czbfdq86jak-xz-mesboot-5.4.5/bin:/gnu/store/khp571gdiz696hl9h0q5p1lw40vz7603-mawk-mesboot-1.3.4-20240905/bin:/gnu/store/0g1ykjrrk4k48d4l3w80ds71nr7iqrf1-gcc-muslboot-4.6.4/bin:/gnu/store/jv736ghsf6szs4i8k8dqvbarh379r6wi-binutils-muslboot0-2.30/bin:/gnu/store/42wdkd4vawy4ma4zgmcs6j494f180a7z-musl-boot- <efraim>1.2.5/bin:/gnu/store/09c7j8lfphd15qyca8p0ycr0fkrzx3b0-gzip-mesboot-1.2.4/bin:/gnu/store/8m8513cm8xwzvhgahj8jbyza7y1za3bx-patch-mesboot-2.5.9/bin:/gnu/store/k37ll4fcr0wqwk3xwamq2f2r1saknhc4-make-mesboot0-3.82/bin:/gnu/store/iaf2d97db3h6mav467i9v3999ab8f9sb-guile-bootstrap-2.0/bin' <efraim>there's -boot0 variants and -mesboot variants <ekaitz>it should only have the mesboot variants once it reached some point <ekaitz>but I think it was somehow just not removing things from the deps <ekaitz>idk, i think it was like this already in guix before <efraim>it is already like this in guix, I'm going to see if I can remove the -mesboot variants since they should've been replaced with the -boot0 variants that have just been built at that point <Franciman2>i very heavily rely on some software that now segfaults <ekaitz>futurile: (sorry I autocomplete betrayed me) <efraim>podiki: mesa builds fine on armhf/aarch64/riscv64, haven't tried powerpc64le but I will soon <apteryx>Franciman: you should never be forced to leave; you can always 'guix package --roll-back', no? <apteryx>also, if the problem is reported, chances it'll be fixed soon <podiki>efraim: great, thanks for the update! <Franciman>hi ekaitz, apteryx. telegram-desktop segfaults for me <Franciman>apteryx: eh i can't roll-back to anything, i should use guix time machine <Franciman>using an older telegram-desktop doesn't fix the issue, because most likely the issue is with guix's glibc <apteryx>the package was updated recently; has the issue been reported already? <apteryx>if you could report it, that'd be a first step toward a potential resolution <apteryx>ideally with an easy reproducer that doesn't require an account or something <apteryx>so that the person applying the fix can ensure it does fix the problem <Rutherther>since it works for some people I would doubt it has something to do with glibc <Rutherther>why would it work for some and not for others if there was a problem in glibc? <Franciman>and it crashes in some C++ code accessing a list <Franciman>it even shows the UI, but then instantly crashes <Rutherther>okay, that's what I had in mind. I currently have telegram running, see chats and stuff. So yes, it works for some. I think someone else here also claimed it works for them <Rutherther>if something like this happens the most common is it's caused by some kind of a state. I already suggested to you to delete the state files. Not sure if you've done that already. <Rutherther>or if you don't want to lose the data you can try starting it as another user <Rutherther>I am on wayland, and can start telegram with both xcb and wayland QT_QPA_PLATFORMs <Franciman>ok cool, i was afraid it was wayland's fault <Franciman>btw when i remove the data, telegram starts up , lets me login <Franciman>then after i log in and it should show the chats, it crashes <Rutherther>alright, so seems a certain condition your account is in triggers it. Mine apparently doesn't satisfy that condition <Franciman>that's why i thought about some global lib like libc <ekaitz>Franciman: did you check if that is reported in telegram-desktop? <ekaitz>it might be an upstream issue we are just carrying <Franciman>I used to be on an older home generation, where i had telegram 4.5.1 (iirc), i mean the version prior to 5.5.5 that we now have <Franciman>so i thought, let's try using an inferior and get 4.5.1 on this new version of guix <Franciman>but it still crashes, so maybe it's not telegram-desktop only fault <Rutherther>Franciman: okay so I am getting segfault when I am clicking randomly on chats after some time <Franciman>oh Rutherther i think the issue may be some outdated dependency <Franciman>Rutherther: 0x00007ffff7fe7c0a in dl_main () from /gnu/store/zvlp3n8iwa1svxmwv4q22pv1pb1c9pjq-glibc-2.39/lib/ld-linux-x86-64.so.2 <mccd>Heya, how do I use the bashrc option in home-bash-configuration? <mccd>it says that the type is text-config <mccd>is there a way to make it read a file? <Rutherther>mccd: yes, you should be able to just give it result of local-file, just make sure to put it to a list <mccd>Another question: I'm noticing that xdm, tty, and my wm (exwm) all have too high of a dpi <mccd>is there any way to configure this? <aadcg>I'm doing string replacement in a package's source files via substitute* and what I noticed it works when setting origin's method to git-fetch but doesn't work when it's url-fetch. can you make sense of it? <mccd>Is there a way to reference mu4e somehow in the emacs config? <mccd>since it is usually in /usr/share/emacs/site-lisp/mu4e <Rutherther>aadcg: so you're doing that in a phase, right? how did you add that phase? <aadcg>Rutherther: correct! via add-after 'unpack 'foo <aadcg>oh, you probably mean that unpack isn't defined for url-fetch? <Rutherther>mccd: what exactly do you want to find? the emacs package files so you can require it? <mccd>I need to add the load-path <Rutherther>mccd: then you don't really have to find anything, just have both emacs and the package in the same profile, and it will be in your EMACS_LOADPATH automatically <Rutherther>guix takes care of this, no need to do something custom yourself <mccd>ah and when you say same profile <mccd>do you mean in my home config? <aadcg>mccd: to complement Rutherther, you sometimes may need to call 'guix-emacs-autoload-packages', in case you install an emacs package while emacs is already running. <Rutherther>aadcg: no, that's not what I meant, the phases should be the same, additionally you should get an error if the phase didn't exist. I was asking just to check if you put it after unpack, since if you accidentally put it earlier I wouldn't be surprised if it worked for folders, but not archives <aadcg>Rutherther: oh I see now, I'll grep through Guix's sources. maybe there's an example <Rutherther>mccd: guix uses profiles to union packages, your guix-home contains one of the profiles. I just wanted to emphasize, that if you did something like: install emacs with system config, install the package with guix install. You wouldn't get the loadpath, as the loadpath is actually coming from the emacs package's search path. So you need to install both with system / both with guix install / both with guix home and so on. Of course you can also put... <aadcg>Rutherther: btw, the error message is "system-error "mkstemp" "~A" ("No such file or directory") (2)" <mccd>@Rutherther allright, and then I don't need to add anything to my load-path? <Rutherther>aadcg: I think that error can be there if the source is not found. Did you try using --keep-failed and checking how the file structure looks like? <aadcg>Rutherther: good idea, will check <Rutherther>mccd: no, you shouldn't need to do that as it will already be added by environment variable. Just note that first time you install a package like that, you will not get the path automatically in your environment, you need to source the profile, a relog should do, or manual source if you want without relog. <mccd>@Rutherther all right thank you <aadcg>Rutherther: the file structure seems to be OK, and, surprisingly, I see other package definitions doing as I do (e.g. sbcl-chemboy). the plot thickens... <Rutherther>aadcg: seems to be OK, as in it is the same for both git fetch and url fetch? <aadcg>it's the same file tree structure yes <aadcg>in the log of the unpack phase I even see the correct paths <Franciman>the clue you posted insde the stacktrace saying that a recursive call goes on for too long <Rutherther>Franciman: though note that my segfault could be different from yours. <dsmith>sneek, later tell dsmith Some Message <luca>Does anyone know of a program that can just pause and never exit that is in the guix repos? <Rutherther>luca: sleep? in core utils. "sleep inf" sleeps indefinitely. Not sure if I got your requirement correctly <dsmith>luca, Used `tail -f /dev/null` for something like that in the past <Rutherther>luca: probably due to the way you are passing in the parameters to the daemon. That list in make-flags should be quoted, only (cc-for-target) should be executed upon evaluation (so unqoute that) #:make-flags `(list (string-append "CC=" ,(cc-for-target)) could possibly work <luca>How does guix know what files from a package to put in PATH? For example /gnu/store/6m8y1h5cad8hdd1h38295m58brvgz6sx-runit-void-20231124/usr/sbin/zzz doesn't show up in my PATH after installing it <Rutherther>luca: guix puts only /bin and /sbin from the packages in PATH, and only if those paths exist. /usr/sbin is not expected be used for binaries, it should be in /sbin <luca>What's the difference between all the gnu/packages/python*.scm files? <Rutherther>luca: it's just different "logical" group of packages <luca>How do I know where to put my python package? <Rutherther>as examples: is it related to building? like setuptools, poetry, etc.? then python-build. <Rutherther>... is it related to none of the specific ones then python-xyz <civodul>there are times when you’re happy the project makes the news on LWN <sneek>civodul, you have 1 message! <sneek>civodul, rlb says: I'll try to run lokke's tests using the new srfi implementation soonish -- I didn't really get a chance to look at the proposal, but that'll at least exercise a good bit. <dthompson>that script was very handy to confirm that I had successfully applied the update <podiki>civodul: as oscar wilde (I think) said, the only thing worse than people talking about you is people not talking about you. <podiki>civodul: will get out a message to the mailing lists when i get home in about an hour or so <futurile>civodul: not connected - but curious - is cbaines (others?) still working on rewriting the daemon in Guile? <civodul>futurile: cbaines was working on it, but i don’t know what the status is <futurile>civodul: OK - I'll ask the next time I see them <theruran>hello - how can I get Guix working with Fedora/SELinux? last time I tried with the install script, the daemon gave network permission errors. is this issue being tracked already? thanks. <graywolf>Hi is anyone knowledgeble about the QA here? I send a patch on October 6th, and I see QA Unknown, which tells me (after clicking it) "Yet to process revision". <ieure>graywolf, Has been my experience the QA is very unreliable and most patches I've sent in have never been processed by it. <graywolf>ieure: I see, so nothing to stress about. Thank you. <civodul>graywolf: it’s been lagging behind lately, not sure what’s up <civodul>i’m not familiar with it but i’m sure it’s an area where help would be welcome (not neccessarily code, but things like monitoring, looking for things that are stuck, etc.) <graywolf>From different topic, I know that guix does not have personal ownership of packages, but do you think there should be at least a rule of "each file should have team assigned"?