IRC channel logs
2023-10-22.log
back to list of logs
<alxsim>Hi, I'm trying to package a python module. It fails on one check that requires internet access with 'error: [Errno -3] Temporary failure in name resolution' <alxsim>Not sure if there is a simple solution to that or if I should just skip this test <podiki>generally need to skip/disable any test that requires network (not available in build environment) <podiki>(exceptions would be ones that don't really need internet but have some internal network or something) <mirai>any examples on how to write a guile program that contains (define foo (mixed-content-file …))) and prints a path to the store for `foo' to stdout? <alxsim>i.e. removing a folder just before the check phase <RavenJoad>alxsim: Add a new phase where appropriate, using delete-file-recursively. Or add delete-file-recursively to a snippet. I believe the new phase method is the preferred one in this case. <alxsim>ok seems I need something like add-before in modify phases, so two questions: where do I find the list of all phases that guix runs? <alxsim>RavenJoad: thanks, I'll try to find out how to add a new phase in the docs <RavenJoad>alxsim: That depends on the build-system you use. All of them are defined in guix/build and guix/build-system. But it is usually safe to (modify-phases (add-before 'check 'remove-thingy (lambda ...))). <RavenJoad>guix/build-system/... exports the list of standard phases for that particular system. <alxsim>thanks, I'm completely new to guile, how would I use the delete-file-recursively in the lambda? <RavenJoad>(lambda _ (delete-file-recursively "path/to/delete")). delete-file-recursively is provided by Guix, not Guile. It is not important for your case, but for future knowledge. <lechner>Hi, may I globally "allow-downgrades" please? I run my own version of Guix and have to use that option all the time. Thanks! <efraim>oriansj: it looks like nomad might've been broken even before the webkitgtk bump to 2.40.5 <nutcase>nckhexen: I am on /etc/guix again. I removed .config/guix/current and did a fresh guix pull and sudo guix system reconfigure and I am no longer on /usr/local/etc/guix . I still have my old generations, just in case you have another idea on how to analyse the source of that issue. <futurile>efraim: thanks for pushing my patches! that's my third contribution to Guix I think <happy> <cdo256>futurile: I had my first patch (documentation) merged last week. I'm hoping to do some packaging once I've had a chance to set up my emacs properly. It's the coolest project I've used in a while! <lechner>Hi, what's the easiest way to enable the Shepherd REPL on a Guix System, please? <efraim>edk2-tools are unsupported on powerpc-linux, and it looks like powerpc64le-linux too <oriansj>efraim: I really wish guix packages were tested as buildable and working prior to merge and that updating one package would not break any others <lechner>my solution is to stay a month or so behind <efraim>I wasn't able to find the commit that nomad was built from, but it looks like it hasn't seen any development in almost 3 years <redacted>nomad appears to be extremely dead. It was a Google Summer of Code project a while back which hasn't seen development since. <oriansj>redacted: fair enough, was just trying out the web browsers available in guix to see which is most reasonable. <redacted>Yeah, I came across it while looking for lispy browsers <efraim>I really like qutebrowser but it keeps on crashing my graphics card <oriansj>efraim: and having to do a line like: qutebrowser --qt-arg disable-seccomp-filter-sandbox true -s content.dns_prefetch false -s content.javascript.enabled false -s content.proxy 'socks://localhost:9050/' doesnt exactly inspire trust <efraim>shouldn't have to disable the seccomp-filter-sandbox anymore, we fixed that bug, and the others can be set in the config file <efraim>but I hear you, that the defaults could be better <vivien>Dear guix, on gnome-team, you are trying to update webkitgtk. But now, the newer version refuses to build with libsoup2. Do you have a plan? <vivien>Ok I take it back it’s easy to fix <lechner>civodul / Hi, i may be seeing a bug in the Shepherd. I'm not sure it find the most recent service definition. How may I enable the Shepherd REPL on a Guix system, please? <civodul>lechner: hi! as per the manual, you can do something like: “herd eval root '(begin (use-modules (shepherd service repl)) (register-services (list (repl-service))))'” <civodul>we should provide a shortcut for that <civodul>efraim: congrats on the ‘rust-team’ merge BTW! <efraim>now I'm working on merging rust-xremap without bumping any key crates <vivien>Is there a plan to merge gnome-team? I understand we should update webkitgtk, but what’s next? Should we also update everything possible in (gnu packages gnome)? (gnu packages gnome-xyz)? <efraim>using the etc/teams.scm script as a rough guestimate, I'd guess glib.scm, gstreamer.scm, gtk.scm, gnome.scm, gnome-xyz.scm, webkit.scm and glib-or-gtk and meson build systems, as they see fit <efraim>The rust-team generally tries to work on anything built using the cargo-build-system, and rust itself <civodul>vivien: teams.scm lists 3 people as members of ‘gnome-team’, i guess you should coordinate with them to check what the plan is <lechner>civodul / Thanks for the 'herd evel root ...' part! Is that so explicitly mentioned in the REPL section in the manual? Would you accept a patch that adds a sentence to that effect? <efraim>something seems to have happened with qemu-minimal, I'm only showing it as supported for x86_64-linux and aarch64-linux <efraim>'guix build' didn't claim it was unsupported for i686-linux <lechner>civodul / Also, while I have your attention, what's the best way to debug when Shepherd shows an error message on starting a service that does not correspond to any current service definitions? https://bpa.st/PTBQ <lechner>after delete-generations and gc, but possibly before a reboot <cnx>in lights of the new zig-build-system, is there anyone packaging LLVM 16 (for the latest Zig 0.11)? <efraim>I don't see anything in the patch tracker about llvm-16 <elevenkb>Downloading substitutes for e.g. guix-cli, etc. is a bit slow right now for me (about 15KiB/s)... may someone tell me when the server will be less busy? <elevenkb>or I could just be patient and wait for 10 minutes or so... :D <lechner>apteryx / Hi, did these Guix bug report end up on the help-debbugs mailing list for a good reason? <nckhexen>elevenkb: I doubt that the server is busy now. <nckhexen>I don't think it's ever been slow because it's busy. <nckhexen>Is it sometimes fast(er) for you on the same connection? <elevenkb>`guix pull` varies in how fast it fetches substitutes for guix-cli etc. by a factor of 10 or so for me. <elevenkb>have no clue why tho, after your comment that is :D. <nckhexen>We suspect peering or other intermediate networking issues, but mainly because we don't know why it happens. <nckhexen>For example, I'm getting ~40MiB/s from ci.guix to my VPS, and I suspect that my link's the bottleneck. <futurile>cdo256: my first packaging contribution was updating an existing package, it was a nice way to start as it limited the mental overhead <futurile>cdo256: highly recommended as a starting point :-) <jaeme>Is there a Guix matrix space? <nckhexen>jaeme: Kind of, as in, there's a Matrix space called Guix. <nckhexen>You can hang out there if you want, but most don't. <vivien>If I send an email to an issue tracker, do the people involved in the preexisting discussion receive the email? <lechner>the only automatic notification an email to the submitter when the bug is closed <vivien>So it is entirely possible that I’m shouting into the void! <vivien>In case lilyp or apteryx is around, I have a couple of fixups for #66480 <vivien>I’ll make sure to CC you next time <elevenkb>Hello there, is there any way to import a crate that isn't published on crates.io <civodul>lechner: apparently shepherd tried to start irc-helper-bot and something there got a list of strings instead of a string <lechner>yes, but the --channel=#guix is no longer part of my operating system declaration <civodul>if you reconfigure and ‘herd restart irc-helper-bot’, then it should get the new command-line arguments <lechner>in some ways, it mirrors a issue i have been having with cached profiles for 'guix shell' <civodul>normally, upon reconfigure, you get something like “Recording replacement for irc-helper-bot” in /var/log/messages <lechner>i'll look, but here is the sole shepherd service definition on my system, post 'gc' https://bpa.st/ENUA please note the experimental channel #juix <lechner>i cannot see inside the corresponding .go <lechner>i did not get a "Recording replacement" message for that service, but "herd start irc-helper-bot" errors out for the reason above, which seems to imply that the service exists <m-e-o>xrdp is compiled with log location pointing inside the store, so it fails to start <m-e-o>lechner: i cloned xrdp.ini and overrode it there <m-e-o>the question however is how the users are supposed to operate it <avalenn>is there any description of RPC protocol provided by guix-daemon ? <alxsim>Is that expected that installing python with guix would not create a python -> python3 link? <lechner>operating systems differ in that point, i think <podiki>alxsim: yes. you can use python-wrapper package instead <efraim>alxsim: guix provides 'python-wrapper' for python-as-python3 <alxsim>I think that's what messes up my guix shell, as trying to have guix shell python provides me with my conda python <RavenJoad>avalenn: The guix daemon is the Nix daemon, so the RPC should be mostly the same, I think. <avalenn>I think UTSL is probably the best way to go. <cbaines>civodul, the thread did look a bit different to me. Compared to #66049 say <cbaines>in the case of #66573, all the v2 patches are in reply to the v1 cover letter <cbaines>whereas for #66049 (which looks normal to me), the first v2 patch is in reply to the v1 cover letter, but then the subsequent v2 patches are in reply to that first v2 patch <cbaines>maybe the --no-thread option to git send-email was used, and Patchwork doesn't like this? <m-e-o>am i imagining it or are pam services completely undocumented <m-e-o>with exception of the limits service <gabber>m-e-o: there's PAM Mount Volume Service, PAM krb5 Service, PAM Mount Service mentioned in the Reference Manual. what specifically are you looking for? <apteryx>sneek later tell graywolf 'command -v unknown' doesn't produce any output, so redirecting stdout to null seems unnecessary <apteryx>sneek later tell graywolf ah, but the output is when the command exists, I see. I'll do the change. <apteryx>vivien: I think we should the latest gnome on the gnome-team branch <apteryx>when that's done we can have it merged <apteryx>yes! that's probably needed by a few latest gnome packages, I'd guess <apteryx>but it doubt, it's best ot consult GNOME's releng file <apteryx>which contains a BOM of all the components they used for a stable GNOME release <euleritian>I heard that lean 4 is written in lean 4. Will it be included in guix? <apteryx>something fun we could do is make a gnome-team.scm manifest or script under etc/teams/gnome/ that'd fetch that file and update all corresponding packages to the versions it lists <jaeme>What is Guix's stance on packages for cryptocurrency? <m-e-o>gabber: xrdp package definition doesnt install its own pam.d file, and there's other things that are wrong, or I have no idea what I'm doing <m-e-o>tldr default xrdp package as is doesn't work <apteryx>lechner: re guix bug reports ending on help-debbugs; I'm lacking context here <mirai>I wonder if it's possible to generate some kind of deterministic “identifiers” that can be used to automatically fill-in the values for certain fields in define-configuration <mirai>I'm looking at an option that can be described as: “The name is meant to be descriptive for humans but is used internally to distinguish between …” <apteryx>perhaps if you explained the use case first it'd make more sense to the rest of us :-) <mirai>my reading is that this field could be represented as a maybe-type within a record-type using define-configuration <mirai>and if the user doesn't manually configure a name then it (deterministically) generates something to use in its stead <mirai>If I'm not mistaken, the name can't be empty <mirai>but there's no meaning to it so we could lift the burden from the user here by automating this <attila_lendvai_>i'm trying to build something (openwrt 19 image with imagebuilder) and it breaks because SOURCE_DATE_EPOCH is not set in my shell env. shouldn't it be set by guix? <mirai>doesn't make sense for that to happen in guix shell <mirai>I think that reading should be done in the context of building (for distribution) <m-e-o>just to clarify, when I define a service configuration, the corresponding packages are installed implicitly, correct? <attila_lendvai_>maybe this is a build env issue of openwrt. it already fails the configure check for git (it tries to grep into something inside git that is wrapped by guix) <attila_lendvai_>i'll just export SOURCE_DATE_EPOCH=$(git show -s --format=%ct HEAD) from my repo that calls the builder <RavenJoad>m-e-o: Depends on what you mean by "installed implicitly". The service-type needs to extend profile-service-type to install something into that profile if you want to access via command-line. But if the service just depends on a program, then it is good enough to reference it somewhere. <lechner>attila_lendvai_ / i think i agree with mirai but i'm not sure <apteryx>lechner: just read the email/replied <apteryx>civodul: hi! I'm curious about that RPM taking 45 minutes to install ^^' <apteryx>do you have the command to generate it locally? <apteryx>attila_lendvai_: in which context? are you packaging it or simply building it in 'guix shell' ? <apteryx>if the later, guix shell doesn't magically set environment variables <apteryx>(except GUIX_ENVIRONMENT or the ones specified by search paths of packages added to the shell) <civodul>apteryx: hadn’t seen your reply, i’ve replied now! <civodul>it’s for CentOS 7, which is super old <attila_lendvai_>later versions of openwrt work fine, so i just patched it up for v19