IRC channel logs
2023-04-27.log
back to list of logs
<jackhill>with the gdb-11.1 failure on aarch64. I know I read about it on the mailing list, but I thought there was a fix. What's the next step there? I can help test, but I'm afraid I don't yet feel comfortable debugging the debugger :) <kitty1>Yo! Wanted to just say congrats on the "full-source bootstrap" addition! <talos>I wanna say my congrats to the Guix team as well. Guix just keeps getting more amazing :D <ChocolettePalett>I wouldn't say it's impossible, but you should consider the amount of time it will take to compile e.g. GNU/Icecat <singpolyma>atka: I would not seriously suggest to run guix on anything that doesn't have both good CPU horsepower and available substitutes. Otherwise you will spend many days trying to install anything. Guix is great, but it's by no means fast :) <atka>singpolyma: yeah that makes sense, I was hoping maybe cross compiling substitutes on my guix server would be possible <atka>I know some are playing around with aarch64 boards like honeycomb etc <singpolyma>Oh, maybe, if you have good network and a beefy CPU nearby. I haven't tried that yet <singpolyma>I tried to use guix on my kids rockpro64 and it decided it needed to compile inkscape. A day later I decided to not use guix in that computer (I was not even trying to install inkscape...) <atka>haha, yeah, I run my arm boards pretty minimal, usually no desktop or anything <singpolyma>The rockpro64 does pretty well. Runs Firefox and YouTube and supertuxkart. Plenty for the kids <atka>I'm looking for a low power desktop replacement, sub 5W if possible <atka>mainly for coding, ssh, light browsing, and running irc/element <atka>currently using a steam deck for that role <singpolyma>I dunno what the power rating is on the rockpro64 but if you just use it with emmc and no fan I bet it's very low. <talos>I would like get a Odroid H3+ and run Guix on it, along with a wireless adapter which would run on the libre kernel. I know ThinkPengiun maybe sells that works with Guix? I just like the fact that the Odroid H3/H3+ is basically like a NUC and is x86. <atka>some of the atom and celeron boards are very low power <atka>depending on what you're doing you can stay around 5W <atka>I use only solar power and like to have a few computers around for different things so low power in the winter months is needed <atka>steam deck is pretty awesome in that regard <atka>need to get a scheme deck going with guix on it :) <apteryx>jpoiret: that was meant to mirai, sorry for the confusion, ah! <apteryx>sneek: later tell civodul in shepherd, the docstring of exec-command says USER can be either a string or an ID (integer), but the code does '(setuid (passwd:uid (getpw user)))', which only works on a string USER. <apteryx>sneek: later tell civodul err nevermind. "1000" is not an integer ^^' <RavenJoad>Does someone have a syncthing configuration I can look at? The manual's documentation is pretty sparse there. <mirai>apteryx: let me see if I understand the issues atm <mirai>is the mpd-service-type âstealingâ your audio card output? <mirai>I'm guessing mpd is launching pulseaudio faster than your interactive user account <mirai>my guess is that some of the values were added for 0.24 which hasn't been released yet <apoorv569[m]>Looks like telegram and ardour (at least in my list of packages) are unable to install due to error with ssl and/or libwebsockets. <rekado>I just fixed libwebsockets (by upgrading it) <apoorv569[m]>rekado: What do you mean by upgrading it? Did you update the package definition upstream? <attila_lendvai>does `guix build quilt` work for you on master? one test fails for me. am i the only one? i don't see it mentioned anywhere, but it breaks my `guix system vm` based workflow. <rekado>apoorv569[m]: Iâve seen this often since the core-updates merge. I think building with gcc-10 fixes it. <rekado>apoorv569[m]: add it to the native-inputs field <apoorv569[m]><rekado> "apoorv569: add it to the native..." <- Any way to do it via command line only? <sneek>Welcome back civodul, you have 2 messages! <sneek>civodul, apteryx says: in shepherd, the docstring of exec-command says USER can be either a string or an ID (integer), but the code does '(setuid (passwd:uid (getpw user)))', which only works on a string USER. <sneek>civodul, apteryx says: err nevermind. "1000" is not an integer ^^' <jpoiret>apoorv569[m]: updating it is probably another solution <apoorv569[m]>Where/How do you send changes upstream. Maybe I can try to update libexpected and see if it fixes then push changes upstream. <andreas-e>efraim et al.: Message to the rust-team: Do you think we could update gdb/pinned to gdb-12 and drop gdb-11? Version 11 does not build on many architectures. This causes a lot of rebuilds since it is used as a native test input for rust. But it is the only place where gdb is an input, as far as I can see. <jpoiret>so I heard back from the people behind lists.gnu.org. basically, having DKIM on with a strict policy (ie reject or quarantine on wrong signature) is what causes mailman to rewrite the From: header. Since mailman rewrites subject and/or in-reply-to for some lists, the DKIM signature would fail, so they also have to rewrite the sender to pass DKIM. <jpoiret>I don't know how that could be worked around (except disabling all features that cause header rewrites) <jpoiret>I would assume it would be completely impossible with debbugs <jpoiret>as a stopgap measure, you can enable format.forceInBodyFrom to force the right From: line to appear in the body, which would then be untouched <jpoiret>I find it problematic though that debbugs completely destroys DKIM <jpoiret>well yeah, they just don't modify anything <efraim>andreas-e: I have that locally on my rust-team branch. I've moved gdb/pinned to a full gdb-12, with gdb-12 inheriting from it <efraim>I haven't pushed it yet because I'm going to need a full rust compiler rebuild when I fix rust-1.54 on riscv64 and I didn't want to queue several thousand aarch64 packages just yet <andreas-e>Yes, it can wait, but it is good to see it is in the planning; reading jackhill's question prompted me to check. <efraim>might end up with 2 commits, one to fix it (apparently it does expect a C11 compiler, gcc-11 defaults to C17), and one to remove some extra inputs <jpoiret>bost: have you upgraded your system generation? <jpoiret>you're probably using readline, which will come from your guix system generation for some reason <bost>jpoiret: I run `guix package --delete-generations=<someN>..<someM>` and `guix home delete-generations` (that deleted all the home profile generations except the current one. Ugh.) and `guix gc --delete-generations=2m` <jpoiret>you didn't need to delete the generations btw <bost>jpoiret: I ran `guix package --upgrade=`. And I ran `sudo guix system ... reconfigure ...` some 5 weeks ago. <jpoiret>but you did guix pull just now, right? <jpoiret>as a temporary stopgap you should be able to do `guix shell guile guile-readline -- guix repl`, or move ~/.guile out of the way <jpoiret>but you won't have readline support in the second case <bost>jpoiret: the list of the generation was getting too long to handle, so I deleted some old generations. <bost>jpoiret: yeah, sure. I ran `guix pull` just a moment ago. <bost>jpoiret: aaah. Thx for the tip. <jpoiret>until you `guix system reconfigure` that is <bost>jpoiret: well yeas I was about to run guix system reconfigure but then I got distracted by some other problem, while solving the other problem I got distracted by some other problem and then I got distracted by yet another problem I then I lost the count... :) <sammm81>hi, is it possible to run a "PreStart" hook, similarly to systemd, in shepherd service? <bjc>sammm81: no, there's no direct equivalent. depending on what you need you right just be able to add what you need to the lambda, though <bjc>âŠwhy am i downloading a substitute for firefox-102.10.0esr? i didn't think guix packaged that, and âguix search firefoxâ doesn't unearth it <sammm81>bjc: ah thank you, pretty new to guile, but I assume something like (lambda .... ( make-forkexec-constructor) (make-forkexec-constructor))? <bjc>you'd only have one âmake-forkexec-constructorâ, which you'd use for the actual service you're running. before that you can use arbitrary scheme to set up the environment you need. i have some services that use â(mkdir-p âŠ)â, for instance, to ensure directories exist, or â(chmod âŠ)â to ensure permissions <bjc>i should read more: it's the source tarball for firefox. so i guess i'm going so be compiling icecat soonish~ <jpoiret>bjc: well, the sources are needed to build icecat and icedove <jpoiret>both are just modified firefox and thunderbird builds <bjc>yeah, i just somehow skimmed over the âsourceâ part of the file name =) <reyman_aw>the latest guix pull & sudo guix system reconfigure fail for me : [809/889] Generating src/fwupd-resources_c with a custom command FAILED: src/fwupd-resources.c <reyman_aw>glib-compile-resources src/fwupd.gresource.xml --sourcedir ../source/src/. --sourcedir ../source/src --c-name fu --internal --generate --target src/fwupd-resources.c --dependency-file src/fwupd-resources.c.d src/fwupd.gresource.xml: Failed to locate â../source/src/org.freedesktop.fwupd.xmlâ in any source directory. <Guest23>hi. when i try the command from the manual to boot the qemu guix vm it fails with "qemu-system-x86_64: failed to initialize kvm: Permission denied". i have virtualization enabled in boot settings and lsmod shows that "kvm" and "kvm_amd" are loaded. when i remove "-enable-kvm" from the command the vm runs. what could be the issue here? using nonfree linux, but that should be irrelevant <madage>It happened to me once as well.. cheers! <jpoiret>reyman_aw: have you looked into it a bit more? <reyman_aw>i give you a more consequent trace of bug if you need <jpoiret>if it's just a build problem i can reproduce locally that won't be necessary <reyman_aw>yes this is a build problem, occuring at [810/889] Generating src/fwupd-resources_c with a custom command <apteryx>mirai: hi! I think we could deprecate 'group' for the mpd-configuration, right? <apteryx>it's redundant with the group captured by the <user-account> record object of the 'user' field <next4th>um, run 'guix show emacs-guix' return 2 instances of the same package for me. <apteryx>it's annoying that group from <user-account> is a string and not a <user-group> <ulfvonbelow>you can't have more than one group with the same name, right? <apteryx>I think the issue I'm looking at is the 'user' and 'group' field of the mpd-configuration <apteryx>they now expect <user-account> and <user-group> objects <apteryx>because tha's what the account-service-type wants to be extended with <ulfvonbelow>I guess that's to require the accounts to be "fresh" and not shared with anything else? Or what does account-service-type do when it encounters multiple group / user objects with the same name? <apteryx>but that introduces the potential for conflicts: <user-account>'s group string is not necesserily the name of the <user-group> object <apteryx>ulfvonbelow: I think the rationale was that the configuration was automated, even at the user/group level, with a sane default (mpd/mpd) <apteryx>perhaps I should just assert somewhere that <user-group>'s name == <user-account>'s group string <Tecjor[m]>Hola, desde ayer me presenta este fallo: building /gnu/store/mhraxa29ppvh1r4v9vcc9nvgzwbh6l3n-libexpected-1.0.0.drv... <Tecjor[m]>20% ââââââââââââââââ âbuilder for /gnu/store/mhraxa29ppvh1r4v9vcc9nvgzwbh6l3n-libexpected-1.0.0.drv' failed with exit code 1 build of /gnu/store/mhraxa29ppvh1r4v9vcc9nvgzwbh6l3n-libexpected-1.0.0.drv failed View build log at '/var/log/guix/drvs/mh/raxa29ppvh1r4v9vcc9nvgzwbh6l3n-libexpected-1.0.0.drv.bz2'. cannot build derivation <Tecjor[m]>/gnu/store/c5nrh3zrwkpq2z3gsya84cashlgvxrha-telegram-desktop-4.2.2.drv': 1 dependencies couldn't be built <Tecjor[m]>cannot build derivation /gnu/store/x5yx4n2vc5bqcih27drhmmihizq8v23v-profile.drv': 1 dependencies couldn't be built guix upgrade: error: build of /gnu/store/x5yx4n2vc5bqcih27drhmmihizq8v23v-profile.drv' failed <apteryx>but that forces the awkward situation that passing my own user object to the user field, I now have to provide the "users" group, which I have to discover by myself and find how to create <apteryx>otherwise it'd complain that "users" != "mpd" <next4th>okay, after a full upgrade, i have one correct emacs-magit again, though the guix binary doesn't changed( <jpoiret>reyman_aw: got a newer version to build <apteryx>so I'm inclined to use the following compromise: obsolete the 'group' field, requiring a the <user-account> group to be a pre-existing one <apteryx>and the default mpd user provisioned would be in the "audio" group, which should exist already on Guix System <jpoiret>sent it to the MLs, someone would need to look at it (I'm not a fwupd specialist, I hope I didn't introduce new proprietary stuff with the update) <zimoun>I get more than often: guix substitute: avertissement : pendant la rĂ©cupĂ©ration de [...] le serveur est plutĂŽt lent <zimoun>guix substitute: erreur : connect*âŻ: <zimoun>guix pull: erreur : entrĂ©e corrompue en restaurant l'archive depuis #<closed <zimoun>Why? I mean, I do not understand why it raises an error and crashes only because the load of the server is heavy. <mrvdb>I have done 'guix install --without-tests=inkscape inkscape' which works. Is there a way to tell packages that depend on inkscape always to use the "no test" version instead of needlessly building and failing inkscape? I also can't seem to produce a list of what packages depend on inkscape for some reason. <zimoun>Basically, I cannot run âguix pullâ. <mrvdb>zimoun using --fallback has helped for me sometimes <zimoun>yeah, me too. :-) Well, I am able to have a working recent Guix. But I have many users that are complaining. <jpoiret>zimoun: might be a problem with the substitute servers <zimoun>Ok, but why an issue with the server raises a crash of the client. <zimoun>jpoiret: it sounds another aspect of #62334 <zimoun>civodul: My guess is a change of Guile side about this âconnect*â. Is it possible? <mrvdb>singpolyma: i see, all the more reason it would be nice if i could say something like, "if using inkscape, always skip tests" <jpoiret>mrvdb: are tests failing on your machine? what architecture is that? <singpolyma>mrvdb: once inkscape is built once it shouldn't need to rebuild, unless they use a different version (where "version" is the precise guix thing not the version number) <jpoiret>Tecjor[m]: just sent a patch for libexpected that updates it to 1.1.0 and makes it build <jpoiret>don't know if Telegram will build with this, but that's a first step <jpoiret>do you know why they're failing? it's a pretty big issue <mrvdb>jpoiret: i can look up what the error is, as to why the tests are failing, not sure <jpoiret>mrvdb: arf, they've also been failing on the CI for a while <jpoiret>I think powerpc is a pretty unmaintained arch <zimoun>ahah! It was in my queue⊠Dealing with emails offline <jpoiret>mrvdb: I think it's a minimal version of inkscape that's used, which isn't the one you get by specifying "inkscape" on the CLI <jpoiret>yes, that would be inkscape/stable, which is hidden <mrvdb>how can I see that that is the case? <Guest15>hi, is changing a package input or a similar trivial operation reason enough to add a copyright notice to the file? is there some guidance for when to put the copyright? <jpoiret>mrvdb: not even sure that upstream cares about powerpc64 though, so it might be quite technical <jpoiret>if it's only a couple of tests though <mrvdb>inkscape itself works fine for me though, it's 3 tests iirc <mrvdb>jpoiret: too bad ppc64 is not very well supported, guix is the ideal distro for the blackbird / talso POWER9 machine <zimoun>civodul: it comes from âopen-socket-for-uriâ that throws an error <jpoiret>mrvdb: we could've prevented this I think, it was showing as failing on CI <jpoiret>well, someone with access to a powerpc machine would've needed to take a closer look though <jpoiret>i'm not building inkscape with qemu on my laptop, that's for sure <zimoun>civodul: I have put good olâ pk around and connect* throw an error when looping. <mrvdb>jpoiret: thanks for your time. I'll create a workaround for myself for now and move on to more pressing things :-) <zimoun>The error is consistent and I am able to reprodue on different machines and network. Well, I guess the bug comes from Guile code and not from the server. <zimoun>Thatâs weird: the servers PyPI and Berlin are both âslowâ, hum?! :-) <jpoiret>btw, I am looking for committers who would endorse my committer status application :) <jpoiret>I feel like my own commits have been piling up more work for current committers, and I can't repay the debt properly for that <reyman>thx jpoiret i try to pull / rebuild to see <apteryx>civodul: it's reproducible, strangely <apteryx>In procedure connect: Le rĂ©seau n'est pas accessible <zimoun>apteryx: yeah, I get the same. Well, I can live with that when itâs about âguix importâ but not when it appears with âguix pullâ, somehow. :-) <RavenJoad>Does someone have a syncthing configuration for the syncthing-service-type I can look at? The manual's documentation is pretty sparse there. <apteryx>ACTION wonders what "guix/records.scm:598:32: error: map-fields: bad use of syntactic keyword" is symptomatic of <bjc>off the top of my head: missing import <apteryx>ah! the <user-account> may not be re-exported like the others <bjc>is (ice-9 match) imported? <apteryx>ah! <user-account> is not even exported <bjc>that particular error has driven me batty a number of times <apteryx>it'd be nice if it was more to the point, e.g. "unknown <user-account> type" or something <bjc>guile needs a lot of work with error reporting <bjc>i wish i were a compiler hacker, just to fix it <civodul>apteryx: if you can file a bug showing how to reproduce it, i'll see if i can come up with macrology to improve on that error message :-) <jpoiret>rekado: thanks! i know andreas also more or less sent one during another mail thread, if that counts <apteryx>I got a 10 line reproduces; sending it :-) <bjc>huh. for some reason, my home config is causing a second build of emacs 28.2 <apteryx>shouldn't make-forkexec-constructor with #:user, #:group and #:log-file create a log file owned by the user/group? <apteryx>the service probably can't even write to it ^^' <bjc>log-file is for stdout/err, isn't it? <bjc>so shepherd writes to it, not the service <apteryx>ah, true. Still, is it not strange that you can configure a service as your own user or in your group, yet not be able to read its log file without root? <bjc>yeah, i'd like to be able to set a umask on it <apteryx>perhaps it can be seen as a security "feature" <mirai>apteryx: re deprecating group, no <bjc>should be a trivial addition to shepherd <mirai>you're misunderstanding what the group does here, when it's a group-record <mirai>it's not added to the account, it's simply serialized to the file <apteryx>but the files under /var/lib/mpd are chown'd to passwd:gid, which may differ <mirai>similar to how #:group works for make-forkexec <apteryx>right; it's problematic to let MPD do the user switching, so I'm proposing to remove that and let Shepherd manage it <apteryx>problematic in the sense that it strips any supplementary groups you may have on your user-account object <apteryx>cutting mpd from accessing your sound card <mirai>apteryx: it makes sense for mpd to do the switching, for lower port bindings or setting io prioritie <mirai>what you really want is a shepherd home service <apteryx>no. I want mpd-service-type to work out of the box :-) <mirai>and perhaps some default config for pulse that doesn't steal the soundcard <mirai>IMO mpd-service-type is for headless/server-like setups <mirai>you're trying to reinvent a systemwide pulseaudio instance iiuc <rekado>yuck, I just discovered awscli@2 <rekado>when you launch it it tries to talk to docker to download awscli v2 and run that. <mirai>but you want for mpd service to work when you're logged with your interactive user right? <mirai>to output sound to the pa-daemon launched by the interactive user <rekado>alternatively, you can run âawscliv2 --installâ and that also downloads binaries and runs those⊠<rekado>this doesnât seem to be an actual package <apteryx>mirai: I've found that two pulse daemons can work just fine side by side (one for mpd, one for my own user) <apteryx>so I'm not doing anything fancy pulseaudio wise <mirai>apteryx: oh ok, then that matter is solved <mirai>or what other issues are you noticing <apteryx>mpd couldn't access /dev/snd/* when running as the default mpd user <apteryx>because it needed to be in the audio group <apteryx>and adding "audio" into supplementary-groups of the default user didn't cut it, because the user/group switching of MPD strips supplementary groups. <mirai>hmmm... I only tested with null sinks and rtp sources since I don't have an audio card on the headless machine I <apteryx>yes, it's code within MPD that does the user switching. upstream recommends not letting MPD manage user switching itself. <apteryx>so I've moved that to use Shepherd's #:user, #:group and #:supplementary-group <mirai>hmmm... that's a dilemma then <apteryx>mirai: it seems a common gotcha of switching users. Shepherd also stripped these until recently (0.9.0 introduced #:supplementary-groups) <mirai>because if we do shepherd switching (which would approximate this to a home service but that's inconsequent) it can't bind to low ports or set realtime io <mirai>group isn't serialized to the file? <apteryx>yep I don't serialize user and group anymore with that change <mirai>can you set the group to empty-serialization for now <apteryx>i've recerated /var/lib/mpd and now I don't see the music collection <apteryx>test suite passes and I can connect though <mirai>the test suite isn't comprehensive <mirai>reading from #mpd it looks like if âgroupâ isn't set then it won't wipe the group and supplementary groups? <mirai>if that's the case then we simply have to change that field into maybe-group-account <apteryx>which low portst are used? it's default port is 6600 <mirai>apteryx: you can elect to use 80 or 1 if you want <mirai>I'd like to avoid overly âopinioningâ the service implementations in guix, they should be as âfree/flexibleâ as their non-guix configured counterparts <mirai>apteryx: re why, you can set a HTTP output for instance <apteryx>you still can, if you know what you are doing (pass user as root) <bjc>imho, it's not a big deal to lose realtime io, and especially low ports, for mpd if you're not running as root. it's a known effect. it should show up in the logs. and if it really matters that much, a note in the guix docs for the service would be sufficient <mirai>well, that's quite a different beast since you're now doing HTTP/codec work at root <bjc>you can stick its http server on a different port <mirai>bjc: the thing is, mpd binds to the ports, etc and drops privileges <apteryx>mirai: ah, so MPD can bind the low ports as root, then proceed to do the user switching and continue using these? <apteryx>for the realtime io, can't it be made to work via the user being in a realtime group? <mirai>I don't know, probably? I think it involves some security.conf magic <apteryx>if we lose just low ports at the benefit of a more configurable user (supplementary groups support), perhaps it's an ok trade <mirai>did omitting âgroupâ from the file do anything? <apteryx>I'm guessing it wouldn't help (I assume the problem to be triggered by the user switching code) but I haven't tried <mirai>I'd like to confirm jast@#mpd comment <apteryx>ACTION is reconfiguring for the 1000th time ^^ <TristanCottam[m]>Guys, is it possible to replace a package's bundled dependencies in place? I'm packaging a Minetest modpack, but the only existing Minetest modpack packages don't substitute bundled mods with their packaged version at all. <TristanCottam[m]>I packaged all of its containing mods separately, but it now seems that was pointless, unless this can be done. <apteryx>home directory permissions are not refreshed upon changing the group of a user; is that a known bug? <apteryx>ah, nevermind, it seems it is after all <jackhill>efraim: I'm trying to understand the discussion in #63008. It sounds like we have a solution to get rust, and thus librsvg, thus grub-efi-bootloader on aarch64, but we're waiting on other rust changed from rust-team before making that avialable. Does that sound right? <efraim>I was reading the post core-updates merge thread and figured I could send an email :) <efraim>on my machine I have x86_64 up to rust-1.59 and I don't expect any problems. I'm only 1 hour in on riscv64, and it normally fails at about 10 hours <jackhill>ah, very good signs. I guess I was king of wondering about making the gdb fix available sooner for aarch64, but it sounds like the whole thing might be soon enough <apteryx>mirai: supplementary groups appears to be preserved when not serializing group <efraim>the branch was mostly ready by the end of february, but we decided on staging and core-updates first, and then also ran into problems with having enough aarch64 build slots <jackhill>for reference, I was hoping to get some aarch64 machines up here so I could engage more with the archetecture, but some of our system examples don't build <apteryx>but then if we were to keep the 'group' mpd-configuration as a field, it'd serve the same purpose as the 'groups' field of the operating-system, which seems pointless, right? <jackhill>right, makes sense. I noted a problem with vulkan-sdk before merge, but figured I'd wait to look into until after all the new stuff landed <efraim>I just picked up some rock64s with 4GB of ram for a project that I didn't finish in time so I might use them myself for building. not sure if it'd be enough to do the rust-bootstrap package, julia or ghc, but should be enough for just about anything else <apteryx>mirai: be prepared for a good amount of criticism in #mpd :-) <mirai>apteryx: eeeh, that field is really only for âserializationâ purposes <mirai>but we should change it into a maybe type <mirai>and note in the docs what that field does and what happens if set/unset <mirai>apteryx: =) I see it's going to be fun <mirai>if it results in an improved service I'm all for it <piethesailor>Using my only machine with guix package manager for the first time in months.. I can't remember/find the answer to a simple problem I have. I am getting an error with 'guix install epiphany'. I have used a flag that is something like --with-substitutes to circumvent this in the past, but that is not valid. Is someone able to refer me to the correct flag? or let me know if I am way off and should consider another solution. <jpoiret>(guix records) feels like a nuke sometimes <jpoiret>very powerful and intricate, but bound to explode at any time :p <piethesailor>Can't paste but I roughly get: the following derivations will be built, epiphany.drv and webkit.drv <piethesailor>after an hour of builing webkit.drv I only get to 28% loaded before I get 'guix install: error: corrupt input while restoring archive from socket <piethesailor>and if I try to rerun guix install epiphany I get: error failed to connect to /var/guix/daemon-socket/socket' connection refused <piethesailor>I am on a Librem 5 so my hardware is super slow. I imagine getting a prebuilt substitute does wonders <unmatched-paren>piethesailor: the corrupt input error is usually printed when a download has been abruptly interrupted (the result is incomplete, thus corrupt) <jpoiret>apteryx: would "unknown location: map-fields: not a bound guix record type in form <user-account>" be better? <jpoiret>well, my code already gives the above <jpoiret>if you want to work on something else :p but it's also good macro zen if you want to flex your muscles <jpoiret>well, once you know how map-fields is supposed to work :) <unmatched-paren>(i was also planning to implement thunked and delayed fields in the same commit series) <jpoiret>it's going to break *all* guix records though <jpoiret>oh, that's a good idea! I'll let you take care of it then <jpoiret>though, it might break some existing code that relies on there not being support <jpoiret>ie delayed fields being explicitely forced <jpoiret>bah, that's some failure for us to patch, let's not prevent innovation because of this <unmatched-paren>a simple grep should* find those cases *terms and conditions apply, please call our helpline if you are unsatisfied with your commits, your statutory rights will not be affected <unmatched-paren>if i understand correctly, you added a hint if the field name is not found? <jpoiret>no, if the given record type is unknown <jpoiret>map-fields is in the error message because it's technically a syntax violation in map-fields, but that could be re-examined <mirai>could we get parent records for record-type* <jpoiret>something like `(record-parent <record-type)` to get the parent of a record type? <mirai>but on the record type itself <jpoiret>unmatched-paren: goops but expand time you mean! <jpoiret>well, I think it's highly non-trivial <jpoiret>and there are some corner-case issues that could be figured out <unmatched-paren>that goes into the box called "entirely possible (even i can see how it could work) but would require a lot of refactoring" <mirai>something like SRFI-136 iirc <unmatched-paren>mirai: what's the use case? i don't think we should go to all that trouble unless there's a decent enough use case <mirai>things like openvpn-configuration (and mpd-plugins) <jpoiret>gomer: meson seems like the recommended way <unmatched-paren>gomer: i think there are a few other gnome apps which use that cursed build setup; might be worth looking at their guix packages <jpoiret>ninja and meson go hand in hand, ninja is a very low-level build system, and meson generates build instructions for ninja to consume <mirai>I could copy-paste N+1 the declaration (or perform macro sophistry like how openvpn-configuration does it) <mirai>but extensible records would make it much more natural <unmatched-paren>mirai: could you create an issue? i might try that one day but not now <mirai>oh, but it would be at bug-guix <mirai>idk if that's a good fit there? <mekeor[m]>mirai: i'd guess you'd need cargo-build-system cuz how to instruct cargo otherwise? <ekaitz>janneke: your blog feed links are broken <ekaitz>janneke: i follow the feed from joyofsource and you are linking to somewhere else in the feed <ekaitz>janneke: (you link to dundal.local) <unmatched-paren>jpoiret: ...never mind again, turns out it now *always* throws the error... <jpoiret>ah, no, I don't think you should be checking for freeness of the identifier <unmatched-paren>i might just apply that (with you credited as the author, of course) and send that with the other improvements <jpoiret>it would maybe be better to throw an error that doesn't mention map-fields in the first case though <rekado>is anyone working on fixing yubico-piv-tool? <jpoiret>deech: hi, this can sometimes be a transient issue, can you retry? <Guest59>I just want to know an ETA for Mate 1.26 in Guix? <jpoiret>i don't think there's any eta on this <deech>jpoiret, yes running it again worked. Thanks! <mirai>unmatched-paren: have you considered improving guile's documentation for the macro system <Guest59>I just really disappointed that last guix version do not come with newer Mate 1.26, so i moved to GNU Trisquel Aramo. <unmatched-paren>jpoiret: i committed your patch with a few changes adding a WITHIN field to MAP-FIELDS, which is used to display ``match-record: ...'' rather than ``map-fields: ...'' <rekado>the elpa/melpa importer is broken: Unrecognized keyword: #:repo->guix-package <acrow>Congratulations all on full-bootstrap. I've got it running on a couple systems now and besides the huge technical achievement the continuing refinements to user experience are evident. It is appreciated. <mirai>apteryx: do we have anything in guix that can set capabilities for programs <Sughosha>Hi all, is sddm not working in Guix? All I am getting is blank screen. /var/log/sddm.log says "[PAM] Closing session", "[PAM] ended." and "Greeter stopped." at the end. <Sughosha>Until the above log messages, all seems fine and before them it says "Greeter session started successfully" <apteryx>mirai: not that I know. nix does it though, using some wrapper scripts <lilyp>Guest59: afaik nothing's really depending on mate, so in theory you can update it whenever <mirai>I wonder if this is something to be done at shepherd level <mirai>a #:capabilities argument to make-forkexec ? <apteryx>seems it'd be clean to do so; does systemd handles that? <mirai>it does, the systemd unit files allow for that <apteryx>for setting up pulse for my mpd daemon, I had to run: 'sudo -u mpd pacmd set-card-profile alsa_card.pci-0000_01_01.0 output:analog-surround-40+input:analog-mono' to use the right card output <apteryx>I guess for simple cards that have only a main output, that wouldn't be needed <mirai>you could adjust the mpd-plugin / mpd-output fields for that iirc <apteryx>if mpd's pulse daemon is started first and playing, it prevents my own pulse to output. the moment I press stop my own pulse output becomes audible <mirai>you'll have to consult the mpd (web) manual on that <mirai>yes that's because the soundcard control was stolen by one of the daemons <apteryx>interesting restarting playback in mpd after my user's pulse is playing, both streams get mixed <mirai>It looks like it shouldn't to me <apteryx>perhaps the card has multiple hardware channels (soundblaster audigy live) or something <apteryx>I'm currently using (mixer-type "hardware") for my output <tremon>are there any pointers/documentation on how to use ocaml as packaged by guix? even the simplest hello world project fails for me with PIE errors: e.g. relocation R_X86_64_32 against symbol `caml_globals_map' can not be used when making a PIE object; recompile with -fPIE <jpoiret>that might be due to the recent big upgrade <tremon>it's a few days old, I'll try to pull again <jpoiret>depends on what you mean by hello world project, but the simplest one-liner hello world compiles and runs without any problems <tremon>If I manually run ocamlopt hello.ml, I get the aforementioned slew of PIE linking errors <tremon>(hello.ml contains just the standard print_endline statement) <tremon>I can get it to work by issuing ocamlopt -runtime-variant=_pic hello.ml instead <tremon>but adding (flags (:standard -runtime-variant=_pic)) to the dune executable stanza doesn't seem to work <jpoiret>what architecture are you running on? <tribals>Doing a `guix build -s aarch64-linux clojure-tools` after fresh `guix pull` will result in: <tribals>This is literally a-half-of-typical-linux-disto if not worse <tribals>How clojure-tools is related to... what, rust?! o_O <jpoiret>tremon: you shouldn't need to add that flag <vagrantc>mirai: there is a WIP patch submitted about capabilities ... <tribals>vala, gtk+, wayland, xorg-server, etc? Are those *really* needed to run java? No! <jpoiret>tribals: that's what you get when you have a full bootstrap <tribals>How, eg, compiler is related with xorg? <tribals>Isn't that should be "just xcb" or so? <tribals>Then *stop depending on GTK* for building java <jpoiret>xorg-server I bet is for running some tests and is not a full xorg-server build <tribals>If gui toolkit requires an apache web server for runtime then such gui toolkit is broken <jpoiret>then icedtea would be missing features <tribals>I belive it needs only some x binding in order to "get features" <jpoiret>they depend on gtk. Every other distribution i've looked at has gtk as a dependency <tribals>It does not matter is it "building" or "just using". In 99 from 100 I need to pull it all. There is not so much substitutes for some platforms, eg aarch64, also. <jpoiret>or maybe icedtea and java in general is broken? <jpoiret>you can't fault packagers for doing what upstream asks for <jpoiret>i agree that the lack of substitutes for some archs is quite bad <tribals>Then, GTK should be limited to the bare minimum <jpoiret>tremon: what's your `guix describe`? <jpoiret>tribals: wdym limited to the bare minimum? we want to run the tests and provide everything gtk claims to provide. since it's quite a complete library it has quite a lot of dependencies <jackhill>I think both things can be true: we definitely can clean up our closure sizes, but upstream isn't really helping us here. <jackhill>aarch64 is indeed not great right now. I think the rust-team branch will solve a lot of that soon, and then we can move on to the problems that are hidden by the current failures <jpoiret>jackhill: i think this is a problem that can be tackled for dependencies lower in the dep graph <jpoiret>but gtk pulling in xorg? seems par for the course. now icedtea wants gtk? that's their choice as well <jackhill>yeah. I'm not sure about the older gtk+, but with gtk we might be able to trim back which gstreamer plugins it needs, but we'd have to be careful to not break features gtk promises to give users :) <tribals>It reduces the whole point of Guix to zero: if you need to build about 2GB of binaries in order to run *anything* soft on such a constrained platform as aarch64 - then there is no point in doing that in the first place <tremon>jpoiret: my current guix is commit: b8b3af93da5340eecab77fa7b12c7ce364bf11cf, but that's because I just did a guix pull. Before that, I came from 5b54576 (4 days ago) <jackhill>tribals: I know you're frustrated, but let's have some optimism otherwise we'll never be able to make progress. Hopefully, substitutes will be available soon. <jackhill>aarch64 substititutes are catching up, but some things just don't build right now, locally or otherwise. <jpoiret>well, rather doxygen is failing, blocking glib. Pretty big blocker, and it's quite a shame we didn't catch that earlier <jackhill>I would say that this shows even more the value of guix: we can have higher confidence that ones something builds we can keep it that way, or at least use time-machine to get it back in a pinch :) <tribals>I saw many times in `guix weather` output like there are 9999 queued builds but, only one was proceeding and it failed. What does that mean? <jpoiret>tremon: you don't have ocaml in your profile? <lilyp>just wanna point out that gtk is not the messy part of the java world <tremon>for some reason, when I updated my dev profile after running guix pull a few days ago, every package got updated except ocaml itself, which is still on the same version from january (ocaml 5.0.0 out /gnu/store/9pa7j2sdlzsvbxczbn1xmnycxaddzz0c-ocaml-5.0.0) <jpoiret>ah no you do, it's very hard to read these profile things <jpoiret>yeah, it's definitely not the right ocaml <tremon>so I'll begin with updating that profile again :D <jpoiret>yes, especially now that you've guix pulled <tribals>jackhill: the problem is that you can't stay outdated really. Some time you need to upgrade. BANG! You can't - it's too big! <oriansj>well /gnu/store/19i2rgfm189j9qpzd3dz39nfpgskqw8f-igt-gpu-tools-1.27.1.drv is broken <tribals>God bless `qemu-static` eventually start working! Now I can not burn my ARM machine... I only needed to update in order to fix `qemu-static` <jpoiret>oriansj: seems that procps now has a library with a different name <tremon>I'll double-check which ld it's using now <jpoiret>ah! you need gcc-toolchain@11 as well <jpoiret>you're using an other, older toolchain probably <bienjensu>I'm trying to run a program in a `guix shell -F` container but it can't connect to the X server that's running. Should I be exporting some more host env/filesystem to the container? <tremon>do I need @11, or is any version 11 or greater sufficient (seeing that there is gcc-toolchain@12 as well) <futurile>bienjensu: yes, the blog post suggest --preserve='^DISPLAY$' <tremon>I see gcc-11 was already downloaded, probably as a package input but not a propagated input, apparently <futurile>bienjensu: this line currently works for me for example: guix shell --container --network --no-cwd ungoogled-chromium --preserve='^DISPLAY$' -- chromium <bienjensu>futurile, adding the `--network` flag and preserving display has moved me onto the next error, thanks <tremon>jpoiret: muchas gracias, both ocamlopt and dune build now work as expected! <bienjensu>podiki, great, thanks. Got starsector working. Mesa wasn't finding display info, just had to expose `/dev/dri` following the chromium example in the blogpost