IRC channel logs


back to list of logs

<rekado>mbakke: this seems to be how most updates to our Python packages come about… :)
<porcupirate>Why does "guix build" build all outputs?
***piyo` is now known as piyo
<mbakke>porcupirate: the outputs are created by the same build job
<rekado>because they are all created at the same time
<porcupirate>Does "guix install" likewise build all outputs?
<rekado>“guix install” is like “guix build” + symlinking. It won’t link all outputs.
<rekado>but if there are no binary substitutes for the output you want then you’ll have to build all outputs locally
<rekado>if there are binaries you can just fetch the item corresponding to the output of interest
<porcupirate>If one output fails, the entire build job fails, correct?
<podiki[m]>yes, it is just one build job
<podiki[m]>any part failing means the build failed
<podiki[m]>often different outputs are just moving things around after built; they are not independent package definitions
<porcupirate>So if there is no substitute for "out" then there is no substitute for any other output?
<mbakke>outputs can be substituted and garbage-collected independently
<porcupirate>But "out" is available to substitute iff any other output is available to stubstitute? For the sake of the `has-substitute?` procedure?
<porcupirate>I can call (has-substitute? store (derivation-output-path (cdr (first (derivation-outputs (run-with-store store (package->derivation package))))))) to check if any output is available?
<nckx>I don't think that holds.
<nckx>The first line.
<porcupirate>How does guix know which output is referred to from specification->package+output
<porcupirate>I see it returns two values...
<porcupirate>So if the output is lost, there's no point in putting the specification in a list of packages? Is there no way to put cataclysm-dda:tiles in my guix home?
<nckx>It's not lost?
<nckx>If you want to include outputs in a simple list you can use something like (map (compose list package->specification+output) (list "blah:bluh" …)).
<nckx>I don't use guix home but I assume the same applies: (packages (append (map (compose list package->specification+output) (list "cataclysm-dda:tiles" "more:outputs" "if:you" "want:them")) (list regular package variables if you want those))
<nckx>Something resembling that remark, anyway.
<nckx>No need for the append and second list if you just write everything as specifications.
<porcupirate>Thank you
<the_tubular83>Why don't you use guix home nckx ?
***the_tubular83 is now known as the_tubular
<porcupirate>Unstable? Putting too many packages in the same profile?
<nckx>No big reason. I'm not feeling a gaping hole in my ~ that needs to be filled, tubes. It's that simple. I'll probably try it out when it's had time to stabilise, and maybe I'll be enlightened, but I doubt it.
<nckx>Manifests nicely take care of the only part of my user account I want Guix'd.
<char>Since I am ont sure why my binary could find the dynamic libraries, it is not working again. Durning cmake, it says the libraries are found. during ninja, no complaints. during runtime, library not found.
<reily>Tests are failing for password-store after latest pull.
<lfam>The password-store error:
<reily>From looking at the ci logs, it looks like the commit that triggered the failure is 2d3bec89b5f7d4dcdfc78a404a06d27639eec83d. I cant quite figure out what's wrong here, though.
<lfam>I'm not sure that it's specifically that commit. Rather, it's something between the commit of the previous (successful) build and the commit you mentioned
<lfam>If password-store's derivation (its build recipe and the recipes of all its dependencies) did not change since then, it would not have been rebuilt in between those two commits
<nckx>The CI does not evaluate each separate commit, it only polls every N minutes and builds whatever commit it finds at the tip.
<lfam>However, I see that password-store does depend directly on 'tree', which was changed in the last few commits leading up to the failed build. So it's likely a problem with the new tree
<nckx>I thought so, but reverting the update commit didn't fix it.
<nckx>I didn't revert all 3 though.
<lfam>It just seems likely to me
<nckx>It is. I expected it to work :)
<lfam>Tree 2 came out last month
<nckx>‘Tree 2’ makes it sound… silly.
<lfam>Heh, I like the first note in the tree 2.0.0 changelog: "Nothing is terribly well tested since there are a lot of changes and I would like to get this out the door finally, please report breakage."
<lfam>Yes, it's quite silly :)
<lfam>Well, password-store bugs can be reported here:
<nckx>I didn't revert to tree@1, that's probably it.
<lfam>I went to look at what Nix does, but they don't run the password-store tests
<lfam>Also I can't find their tree package
<lfam>Ah, "pkgs/tools/system/tree/default.nix"
<lfam>They haven't updated yet
<lfam>Ditto for Arch. So we are probably in uncharted territory
<lfam>This is a great opportunity to fix a bug
<nisha>Hello! I am trying to get package definition generated by `guix import` to build but I get an error "unbound variable". I am not sure what's wrong. Can anyone help? My .scm file is here:
<lfam>nisha: I can help you with that
<lfam>What the importer gave you needs a little extra work in order to be build-able
<nisha>lfam thanks! I figured it needed some extra work, but I think what is in there is accurate?
<lfam>First, you need to wrap the (package ...) in something like (define python-tern (package ...))
<lfam>Then, you need to make this Scheme file "return" the package you want to build. Then, you'll be able to do `guix build -f yourfile.scm`
<lfam>It will fail, because you still need to import the modules that contain the dependencies. Guix will give you a hint as to what they are
<lfam>For example, (gnu packages python-xyz) and (gnu packages python-crypto)
<lfam>However, this package has some dependencies that aren't yet part of Guix, such as python-debian-inspector
<lfam>You used the pypi importer, right? I think you need to do it again with the --recursive option in order to import unpacked dependencies
<nisha>I thought I did use the --recursive option. I will try again. Thanks again for the guidance lfam!
<lfam>When I try `guix import pypi --recursive tern`, it does add a bunch of other packages, and also takes care to "wrap" them in the define-public expression
<lfam>Hopefully from there, it's only a matter of importer the modules that contain the dependencies that are already part of Guix. But maybe there will be some manual fixes required to get everything to build
<lfam>I meant, to write "only a matter of importing the modules that contain the dependencies". Of course, this a different kind of "importing" that what `guix import pypi` does :)
<lfam>Fedora trying to make bold changes to improve the distro: <>
<nisha>lfam I am a little confused about how to import the modules. Is ttps:// a good example of it?
<nisha> (sorry for the incomplete paste)
<lfam>nisha: That's an example of how we import modules in the GNU Guix distro. So, if you aim to contribute your packages to the distro, then you should do it like that
<lfam>But, the method you had in your original paste works too
<alMalsamo>Hi is there some live environemnt I can test Guix with? I want to see if my new ath9k card works and the 1.3.0 ISO doesn't have networkmanager
<lfam>nisha: You would just add, for example, (gnu packages python-xyz) to use-modules
<lfam>alMalsamo: I don't remember the details, but can't you get on wifi in the installer?
<lfam>The 1.3.0 ISO, that is?
<podiki[m]>is there a preference between fixing paths in a package (e.g. something it wants to run by name) or wrapping with PATH?
<podiki[m]>all things being "equal" in terms of work or ease
<alMalsamo>lfam: Hmm well there is no nm and i don't know how to use wpa_supplicant really
<lfam>alMalsamo: I think the installer has a page that sets up wifi for you
<lfam>podiki[m]: The former. Wrapping causes lots of problems
<podiki[m]>lfam: thanks, makes sense
<podiki[m]>funny looking at my earliest packages what I did, now wouldn't think of wrapping for PATH but was wondering if I had a good reason (don't think I did)
<lfam>Like, some programs care about what they are called. So when they are called .foo-real, they don't act right
<lfam>And .foo-real can end up in the UI, and confuse users
<lfam>It's just kind of hacky
<podiki[m]>yeah, I've seen that
<podiki[m]>like the syncthing-gtk desktop file it writes (patched recently to avoid that and store pathing issues)
<podiki[m]>since it gets its running process name/path
***jonsger1 is now known as jonsger
<lfam>Patching the paths is just a lot more robust and doesn't really cause any problems that I can recall
<podiki[m]>it is a kinda clever hack though
<lfam>Yes, and it's necessary in a lot of cases
<podiki[m]>the wrapping, as a last resort
<Noisytoot>KE0VVT, yes
<porcupirate>I have a long list of packages and I need to check if they can be substituted. I don't want to overwhelm the substitute servers with all those individual https requests. Is there a way to filter a list of packages with these constraints?
<porcupirate>I need it to output a list of packages.
<porcupirate>Looks like substitutable-paths can get a list of all the paths that have associated substitutes. Is there a way to get a list of package names from the paths?
<cbaines>substitute servers are meant to respond to lots of requests, guix weather for example makes a request per package for all packages by default
<cbaines>it does do that in batches on one connection though, which reduces the overhead at both ends
<cbaines>as for working back from a store item to a package name, there's no reliable way to do that
***califax- is now known as califax
<porcupirate>Does substitutable-paths use a single connection? Would (filter has-substitutes?) use a single connection?
<porcupirate>Assuming has-substitutes uses the same connection
<cbaines>Maybe, I'm not quite sure
<cbaines>I'm only familiar with querying for substitutes without going through the guix-daemon
<porcupirate>How is that done?
<cbaines>I'd take a look at the lookup-narinfos and lookup-narinfos/diverse procedures in (guix substitutes)
<cbaines>unfortunately I have no more time to chat now though o/
<jgart>does anyone know of any python app in upstream for which there is a guix system service written for it?
<jgart>here's one not in upstream:
<porcupirate>I submitted a patch to make a guix service for jupyter. Not upstream though, still needs work.
<porcupirate>By "upstream" you mean the guix repository?
<porcupirate>Do I understand correctly that someone is working on a way to share substitutes with gnunet?
<jgart>by upstream, I mean GNU Guix
<jgart>porcupirate, is this your patch?
<porcupirate>Yes. Been busy, haven't been able to fix half the stuff they pointed to.
<char>the solution to my problem earlier with not finding dynamically linked libraries is to remove pkg-config from inputs.
<char>I'll correct myself. it was --pure
***lukedashjr is now known as luke-jr
<PurpleSym>It seems qtwebengine has an issue with finding locally installed fonts. Do we have a ticket for that somewhere?
<mothacehe>hey guix!
<PurpleSym>Good morning mothacehe !
<jonsger>I think someone needs to correct the topic :)
<nckx>jonsger: What's new?
<jonsger> is not down anymore...
<jonsger>ah, nop its not the topic, its a message from ChanServ :)
<nckx>It was never down.
<nckx>Let's see if there have been any more official status updates in the IRC backlog… :)
<nckx>Hola: 12 Jan 10:42:33 <rek ado_> according to IT the network problems have been fixed yesterday night
<nckx>Shall we trust this ‘IT’ person?
***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | | videos: | bugs & patches: | paste: | Guix in high-performance computing: | This channel's logged:'
***ChanServ sets mode: -o nckx
<jonsger>always trust the IT :P
<rekado_>interestingly, the IT of the Berlin Institute of Health (which has their servers in the same building as our data centre) disagrees and expects the problems to last for a couple of days longer.
<rekado_>go figure
<civodul>Hello Guix!
<nckx>Hullo civodul.
<jts>Hello. I'd like to try out Guix, but I can't seem to get the live image to boot. It begins outputting kernel messages and then just stops. I was getting errors related to pcspkr and sp5100_tco, but after some web searching I disabled those modules in the Linux commandline via GRUB. Now the only message I'm seeing is an error from udevd saying "no sender credential received, message ignored." Does anyone know what may be causing this and how
<jts> I might resolve it?
<jts>this being, the hang on boot
<jts>Oh, before the udevd message I also see, "error in finalization thread: Success"
<jpoiret>the "Error: Success" thing is normal, it's a Guile perk
<jpoiret>are you trying out in QEMU or on actual hardware?
<jpoiret>pcspkr being already registered isn't an issue i think, I have that message on boot as well
<jpoiret>when you said "live image", are you talking about the installer? if so, did you choose the stable or latest one?
<jts>I do mean the installer, and I chose stable
<mothacehe>jts: is your hardware using a GPU?
<jpoiret>oh, i forgot the installer uses kmscon and so fbdev
<jts>Yes, an AMD something something (it's a hand-me-down gaming desktop)
<jpoiret>I was thinking it couldn't be an issue but heh
<jpoiret>which AMD exactly? some AMD GPUs require proprietary blobs to run
<mothacehe>you might try to disable the GPU in the BIOS to confirm that it's causing your boot issue
<jpoiret>or was it only under ATI that it could run without any
<jts>I disabled the amdgpu driver and got it to boot to the installer, so I think that was the issue.
<jpoiret>you can check at if your specific AMD gpu requires proprietary blobs to run
<jpoiret>hmmmm, I never run `zinit update`, only to discover today that the initial repos of zinit were deleted
<jpoiret>SWH really is a gift
***pritambaral is now known as prite
***fiesh_ is now known as fiesh
<jlicht>I misread that as "SWH really is a grift" and had to do a double take ;)
<bost>Hi. I've installed postgresql 13.3 and cannot upgrade to 13.4. But the 13.3 is no longer available. Does anybody know how to get it?
<bost>$ guix install postgresql@13.3
<bost>guix install: error: postgresql: package not found for version 13.3
<asdf-uiop>hello guix!
<bost>$ guix package --list-available=postgresql | grep "^postgresql.*13\."
<bost>postgresql 13.4 out gnu/packages/databases.scm:1105:2
<asdf-uiop>Any ideas why I'd get for certain packages: "guix style: error: mkstemp: Read-only file system" ?
<roptat>asdf-uiop, I think guix style tries to overrides the package definition it finds in the store
<roptat>bost, why can't you upgrade to 13.4?
<asdf-uiop>roptat: thanks! weird that it does that for some and not for others.
<asdf-uiop>I pressed enter too soon: the one that worked probably just was correctly styled
<bost>roptat: I get 'invalid value for parameter "lc_messages": "en_US.utf8"'
<NicholasvonKlitz>I'm currently packaging the latest version of nextcloud-client, but it depends on a source file from the kirigami package which is not included in its outputs by default (wheelhandler.cpp). What is the recommended way to continue forward?
<NicholasvonKlitz>NicholasvonKlitz: Do I modify the current kirigami package to copy the applicable src file to the outputs?
<NicholasvonKlitz>These are the corresponding files:
<bost>roptat: my postgres.log says also that postgresql.conf contains errors, but it doesn't say anything more specific about them.
<paul_j>Hi guix!
<paul_j>Quick question: I have a system shepherd service called term-auto which is currently stopped, and doesn't restart. What is the purpose of this service, and would I expect it to be stopped?
<paul_j>I am playing with a VM installation on QEMU and noticed this, but the same service on my laptop is also stopped at the moment.
<roptat>bost, mh, I don't use postgresql, so I can't really help, but maybe you should look at documentation about migrating to the newer version? maybe something changed with the configuration?
<roptat>paul_j, I don't remember what it does, but I think it's expected to be stopped
<roptat>paul_j, herd doc term-auto → Run agetty on a tty.
<paul_j>roptat: that's good to know. Everything seems to be working OK, so I wasn't unduly concerned, but when updating the system I get the message about restarting services so I thought I had better educate myself!
<paul_j>roptat: I hadn't come across the doc option - thanks!
<roptat>NicholasvonKlitz, does it really need that file, or can it use the library from the system? depending on a cpp file is unusual
<bost>roptat: I definitely should do that sooner or later. But for the moment I thought I'd stick with 13.3 and that should be easy since I use guix... but it's not. Ugh.
<roptat>you can roll back to a previous generation where you had 13.3
<mothacehe>bost: you can also define you own 13.3 package inheriting from postgresql-13
<roptat>or use an inferior to fetch the package from a previous guix revision
<bost>roptat: by inferior do you mean `guix install postgresql@13.3`? That doesn't work.
<roptat>no, "inferior" is guix jargon, it refers to using a package definition from a previous guix revision
<roptat>you can only use inferiors when writting guile, not from the CLI
<roptat>you can use inferiors in manifests and operating-system declarations
<bost>roptat: Actually I'm trying to do that since about a half an hour. The last commit with postgres 13.3 is the afe8ecd and I took the gnu/packages/databases.scm from it and now I'm trying to add it to my own channel.
<roptat>that's not the same as an inferior
<roptat>but that's fine
<roptat>make sure you have a different file name from your channel, and rename the module in the file (define-module (foo bar databases)) if it's in foo/bar/databases
<roptat>er, foo/bar/databases.scm
<efraim>does anyone have an example of conditionally adding an input using the new labelless input method?
<roptat>(inputs (append (if condition (list a) '()) (list b c))) ?
<efraim>I'm trying to make pandoc a conditional input on earlyoom
<bost>roptat: aaah the name collision in the (define-module ...) was the problem. Thanks!
<efraim>moving the condition outside of the list is probably what I need
<bost>roptat: anyway, what is that 'inferior' thing and how can I use it?
<bost>roptat: Thanks again!
<bost>roptat: ... and it seems like my real issue is not the postgres 13.4, but it has to do something with the 'invalid value for parameter "lc_messages": "en_US.utf8"'. And looks like something about 'locale' (whatever that is).
<roptat>mh, locale is about your computer's language
<roptat>en_US.utf8 looks correct though...
<roptat>maybe an issue with glibc versions?
<roptat>I don't think that's even possible...
<roptat>which command returns that error exactly?
<bost>pg_ctl -D ./var/pg -l ./var/log/postgres.log start
<abcdw>Can someone try to do `guix pull && guix time-machine --commit=a79ad5fce5 --disable-authentication -- describe` ? or any other commit you didn't build earlier.
<bost>it doesn't help to install the glibc - I just tried that.
<bost>abcdw: I'm trying...
<bost>building /gnu/store/35i4ybxf8q9zjv9b3phd2r0x30yi27q0-nonguix.drv...
<bost>|builder for `/gnu/store/35i4ybxf8q9zjv9b3phd2r0x30yi27q0-nonguix.drv' failed to produce output path `/gnu/store/zs32qwgaw7b05lpdcya7r1qg7pzai3ac-nonguix'
<bost>build of /gnu/store/35i4ybxf8q9zjv9b3phd2r0x30yi27q0-nonguix.drv failed
<bost>View build log at '/var/log/guix/drvs/35/i4ybxf8q9zjv9b3phd2r0x30yi27q0-nonguix.drv.bz2'.
<bost>cannot build derivation `/gnu/store/xxc5217fbv7sv1sb3640jdwxrk6j37rs-profile.drv': 1 dependencies couldn't be built
<bost>guix time-machine: error: build of `/gnu/store/xxc5217fbv7sv1sb3640jdwxrk6j37rs-profile.drv' failed
<bost>abcdw: do you need the drv file?
<abcdw>No, I just checking that it fails not only for me.
<roptat>abcdw, bost but that's failing in a different channel, not guix itself
<roptat>need to go though, can't help, sorry
<abcdw>roptat: Seems it failing in a clean guix installation too. I did `guix time-machine --commit=0f869287ebf -- time-machine --commit=a79ad5fce5 --disable-authentication -- describe` on a separate machine.
<bost>abcdw roptat yep, you're right. Retrying...
<bost>abcdw: that fails with:
<bost>ice-9/boot-9.scm:1685:16: In procedure raise-exception:
<bost>In procedure string->utf8: Wrong type argument in position 1 (expecting string): #<derivation /gnu/store/qy1h19sfygc5v21kb8ds9w61vacb7gsr-profile.drv => /gnu/store/30v6ldrfig5bc7nv335bvsfswxag8sf3-profile 7fecc3f2f6e0>
<abcdw>bost: Just in case, it is a separate topic not related to your previous discussion with roptat :)
<bost>abcdw: I know :)
<abcdw>bost: Thank you for checking it =) Maybe someone else can try to reproduce it? civodul, efraim.
<NicholasvonKlitz><roptat> "Nicholas von Klitzing, does it..." <- Yes it really does depend on the file.
<NicholasvonKlitz>There are other third party dependencies like this in nextcloud-client and they are resolved by substituting the source from with the sources files included in the outputs of the respective package (ex for KWidgetAddons). This doesnt work for kirigami because the required source files are not included inthe package outputs
<civodul>abcdw, bost: could you email bug-guix with a reproducer?
<civodul>i have a hard time following the discussion in my backlog :-)
<abcdw>civodul: Done.
<g_bor>hello guix!
<g_bor>I just gave a try to guix home in a more or less new install
<g_bor>maybe I am missing something, but after initial setup I tried a guix home reconfigure, and it is complaining that the users's per-user profile directory does not exists
<g_bor>shouldn't it be created by guix home?
<civodul>abcdw: thanks!
<civodul>g_bor: hi! per-user/$USER is created by the daemon the first time a client connects
<g_bor>ok, so guix home reconfigure does not qualify, because of what?
<g_bor>I assume there is some ordering issue here...
<attila_lendvai>i think this should get higher priority: (gnome touchpad settings don't work without this)
<g_bor>I will try a completely fresh install today to confirm this
<g_bor>basically guix home seems to be trying to use it before it exists
<GNUHacker>any recipe to setup a mail server in guix?
<abcdw>g_bor: If issue still persist, please report it to bug-guix and CC me.
<bost>roptat: For the record - it turns out when updating postgres 13.3 -> 13.4, my postgresql.conf needs to have following params activated/deactivated:
<bost>unix_socket_directories = '/tmp' # comma-separated list of directories
<bost># lc_messages = 'en_US.utf8' # locale for system error message
<bost># # strings
<bost># lc_monetary = 'en_US.utf8' # locale for monetary formatting
<bost># lc_numeric = 'en_US.utf8' # locale for number formatting
<bost># lc_time = 'en_US.utf8' # locale for time formatting
<jpoiret>why do so many things try to use en_US.utf8 even though it does not exist
<g_bor>attila_lendvai: what is the expected result from that bug?
<g_bor>do you think the defualt settings should be changed?
<attila_lendvai>g_bor, that the touchpad settings actually do something in the gnome settings app
<attila_lendvai>g_bor, without the proposed fix, changing e.g. natural scolling does nothing.
<g_bor>oh, ok, maybe the bug was just too long...
<g_bor>at the beginning there was a discussion about how to modify the config to get it working
<bost>roptat: however the locale related parameter values may need a deeper look. Among others I get 'guile: warning: failed to install locale' when starting `guile` from the command line.
<attila_lendvai>g_bor, yeah. this is the fix that i need to carry in m config for it to work:
<jpoiret>the fix is actually to not use Xorg at all
<attila_lendvai>maybe a proper issue should be opened for this (if only we could edit issue titles and body in debbug...)
<attila_lendvai>jpoiret, on wayland that fix is not needed?
<jpoiret>libinput is the standard input driver on wayland
<g_bor>attila_lendvai: I would suggest to open a new issue with a narrower scope, that might allow this to be tracked more efficiently.
<g_bor>you can link the current one to it
*attila_lendvai removes this from his config and tries now that he's on wayland
<jpoiret>i still have my Xorg config inside my config.scm, but it doesn't do anything, i should remove it as well
<g_bor>jpoiret: that seems to be a bit heavyweight suggestion to me
<jpoiret>that was meant as a humorous comment, although I do believe that we should switch to wayland by default
<jpoiret>for Guix, it's just a matter of setting a flag
<g_bor>jpoiret: I also think so, and I have done so long ago
<jpoiret>last time I tested, GNOME works out of the box with (wayland? #t)
<g_bor>this however opens up the possibility to actually change this default
<jpoiret>but i didn't check on actual hardware to see if touchpad and all did in fact work properly
<g_bor>actually the way gnome is configured is a bit painful for me.
<Guest18>is it possible to install a package to the system profile without having to do a full `guix reconfigure`?
<g_bor>It would be great if we could do declarative config also there, so we can use version contol on the settings
<jpoiret>g_bor: I agree, but the issue is that GNOME is not very well suited to these use-cases
<Guest18>jpoiret: was that no for me?
<jpoiret>I'd be in favor of having a well-configured modular wayland session present along other big DEs
<jpoiret>Guest18: yes
<Guest18>ok thank you
<g_bor>yep, I agree, I actually had a look into it, but it was not promising
<jpoiret>my current config with sway+GDM is very good for me, I have all usual perks of DEs (minus GUIs for settings), but it's still sway
<jpoiret>maybe wayfire with the proper plugins would be more appropriate
<jpoiret>there's potential here to leverage these more focused projects. They cause much less friction than big DEs
<g_bor>actually there is chicken scheme bindings for wlroots, I think we could do something for guile
<jpoiret>wlroots is big though, it would be hard to maintain
<g_bor>jpoiret: it depends mainly if it can gain traction or not
<g_bor>Now guix system does almost everything that I need to get a very sane workflow
<g_bor>If we could land something like this, that would be big enabler for desktops
<civodul>g_bor: that may be a "guix home" bug; it seems to open the daemon connection pretty late, possibly after it's tried to access per-user/$USER
<civodul>could you email bug-guix?
<g_bor>civodul: I will do a full resinstall ,confirm it, and then send a proper bug report, with info to reproduce
<KarlJoad>Maybe I'm just uninformed, but why does Shepherd have such a hard time following processes sometimes? Like forking ones?
<jpoiret>wdym by having a hard time following processes?
<nckx>KarlJoad: Is it even possible to reliably follow forking processes at all without using cgroups? Because then the answer is ‘Shepherd doesn't use cgroups’. Bit circular, true, but that was my understanding :)
<jpoiret>oh, you mean if the process that shepherd starts itself forks?
<nckx>The traditional method is to use PID files but that's not really following, more like trusting your teenage kids to always truthfully tell you where they went.
<jpoiret>nckx: but wouldn't you expect the daemons you're running to be able to report the proper PID?
<nckx>jpoiret: The daemons it herds.
<nckx>jpoiret: The Shepherd certainly does.
<jpoiret>i'd say it's more a daemon bug than the init system's
<nckx>People expect more from their init systems today.
<nckx>It was normal in the ~90s.
<jpoiret>i expect my init system to be able to launch containers with services embedded in signed usb devices
<jpoiret>- every systemd user ever, including someone's 60-yo grandma
<jpoiret>for anyone who hasn't done this yet, I suggest reading the latest systemd version changelog. It's quite entertaining.
<nckx>I expect my init system to not routinely lose track of foo-d so ‘herd restart food’ fills the log with ‘can't frotz, is foo already running? disabling service foo’. Clearly my expectations are unreasonable.
<jpoiret>but isn't that foo-d's problem?
<jpoiret>it reports a PID, shepherd simply does what it's told to
<nckx>Not track processes? Yes.
<nisha>Hello! This might be a stupid question but how to I "return" a package name in my package .scm file?
<nckx>nisha: Just add the variable name (define-public NAME) to the end. A file evaluates to the last expression in it.
<nisha>nckx thanks!
<nisha>that worked!
<smarton>Hi Guix! I notice that guix pull outputs multiple time "substitute: updating substitutes...". Is there a technical limitation why this can't be done just once at the beginning?
<jpoiret>between having daemons that behave as proper daemons or relying on cgroups, i'd rather have the portable option. But I guess systemd was created because people had different needs
<GNUHacker>any recipe to setup a mail server in guix?
<civodul>smarton: hi! it's usually done just once, except when you've configured several substitute URLs or similar
<civodul>(or when something goes wrong)
<nckx>jpoiret: The name is just rather ironic when the answer to ‘why can't it even reliably herd services’ is ‘you are wrong for expecting it to try, systemd fanboy’.
<nckx>civodul: Isn't it also due to grafts?
<jpoiret>when you put it like that... :p
<jpoiret>Shep it is then
<civodul>nckx: should be rare:
<nckx>Oh good.
<utkarshsingh>Where do you find base32 hash for a Github software release?
<sneek>Welcome back utkarshsingh, you have 1 message!
<sneek>utkarshsingh, robin says: i think the netfarm author hangs out in #lispcafe, nick 'hayley', fyi (she's also a sicl hacker possibly?)
<smarton>civodul: hmm... I ran the first pull on a fresh Guix System 1.3 and that line appeared at least a dozen times. Reconfigure is running now and it appeared just in the begining however, so I guess showing it only once is a newer feature
<jpoiret>looking at the Guix Days announcement, it seems that the "look at the last edition's topics" part links to the announcement, not the schedule of the latest edition
<jpoiret>ie there are no topics on the linked page
<jpoiret>it should be instead
<xelxebar>What am I doing wrong here? With `hello' this built, but with my custom package it doesn't: (run-with-store (open-connection) (mlet %store-monad ((hello (package->derivation hello))) (build (list (derivation->output-path hello)))))
<xelxebar>With my custom package, it just returns #t, but with `guix build --file' it starts a build as expected.
<nckx>utkarshsingh: The safest way is to clone a clean copy of that repository, cd into it, then run ‘git reset --hard 2.6.4’ and ‘guix hash -rx .’.
<KarlJoad>nckx: Is there a technical reason shepherd does not use cgroups? Or is it a legacy thing?
<nckx>If you don't actually bother verifying your checkout (or they don't sign their commits anyway), you could also write a provisionary package with a bogus hash (copy one from another package), try to build it, and Guix will complain & spit out the correct hash.
<nckx>KarlJoad: I don't know and I don't know if I want to know.
<jpoiret>KarlJoad: I think Shepherd (known as dmd when the project started) predates cgroups
<KarlJoad>Fair enough. jI guess that is more
<jpoiret>also, those namespacing features are pretty technical and hard to get right
<jpoiret>especially cgroups
<KarlJoad>The legacy and techncal reasons make sense. I bet there is a mailing list thread somewhere about it. I should go spelunking for it.
<apteryx>shepherd has its own mailing list
<apteryx>hmm, not sure actually
<apteryx>I had mcron on mind
<jpoiret>and last, Shepherd's main goal is to be the init system of the GNU os, so it won't use non-portable features like cgroups, since it also wants to run on the Hurd
<g_bor>I have just observerd an interesting bug in the installer
<g_bor>I have't seen it before
<utkarshsingh>nckx: Thank you!
<xelxebar>jpoiret: You consistently give on-point answers. So annoying :P
<g_bor>what happened is that the devices were detected the other way around that they usually are, so instead of just clicking through everything I actually had to update the device selection, as the install CD was selected
<jpoiret>g_bor: are you using stable or latest?
<jpoiret>it should be fixed on latest
<KarlJoad>jpoiret: That last one is... frustrating, but understandable. I guess an alternative would be to add a cgroups-like feature to Hurd...
<jpoiret>ie the install media (USB/CD/etc...) should never appear in the list
<g_bor>After that the install went fine, but at the end an exception with a backtrace was thrown at me, and rendered the whole machine unusable ( I could not click on ok )
<g_bor>Anyone has seen something like this?
<Guest19>perl and python are not on my path. Should I install them to the system profile or do I just need to update my path?
<g_bor>The new install went just fine after that
<jpoiret>well, I see installer exceptions all the time, but it would help if you had the exception+backtrace somewhere
<Guest19>This is the only linux system I have used where perl and python are not on my path
<jpoiret>Guest19: what do you want to use them for?
<jpoiret>most likely, you'll want to install them to your user profile, via "guix package -i python perl" (or whatever their name is)
<Guest19>I write programs in perl and python and use perl on the CLI
<g_bor>jpoiret: It would have been hard to report it propely, it was basically a wall of text in a screen where you could do nothing with it...
<jpoiret>if you use perl on the CLI, I suggest installing perl
<jpoiret>if you use python only for programs, you can temporarily launch a shell with python in it with "guix shell python"
<jpoiret>you'll see that you can use python in that shell without it being installed in your profile
<jpoiret>g_bor: we're working on improving that, with the option to make a dump archive and send it to a server
<Guest19>Ok I understand. In general I am having trouble knowing when I should install a package to the system or user profiles.
<jpoiret>but it's unfortunately not in master yet
<KarlJoad>Guest19: For a single-user install, that can be confusing.
<g_bor>jpoiret: It is nice that yopu picked it up
<Guest19>My install is indeed single-user
<KarlJoad>But, think of it this way, if other people were to have a user account on your computer, would they need it?
<jpoiret>Guest19: generally, you only have to install things in the system profile if they're going to be run before you log-in, ie outside your session
<KarlJoad>My thing applies to system users too (www-user) in addition to human users.
<KarlJoad>Installing things to the system profile also means that system rebuilds may take longer as there is more of a "world" to rebuild.
<g_bor>I was mentioning the strange order of device detection as I assume it was maybe trying to unmount the install media instead, and hitting busy that way. But I don't know for sure.
<g_bor>This kind of issue is just hard to reproduce.
<Guest19>ok now it makes sense
<jpoiret>g_bor: oh, for sure! if it was showing you the install cd, then later on it would've waited for it to become available
<jpoiret>that should be it
<jpoiret>but this should be fixed on master
<KarlJoad>Question for the Guix developers here, how do you manage mailing lists? I want to subscribe to them, but want to have them locally.
<g_bor>ok, it might be a false positive
<g_bor>this is a fresh install from 1.3.0
<g_bor>sorry for the noise then
<jpoiret>KarlJoad: you can download emails, I use mbsync personally
<jpoiret>and notmuch for indexing
<Guest19>I use mbsync as well for mailing lists but also look at offlineimap
<KarlJoad>I use mbsync and mu right now. I have seen others using l2md and wanted to see if there may be a technical benefit to that.
<nckx>+1 on mu/mbsync but I'd never heard of l2md…
<nckx>Ah, it's list only, never mind.
<nckx>I mean, archive-only.
<KarlJoad>It does seem to be able to export to maildir after grabbing all messages.
<Guest19>while the topic comes up, I could not find mu4e in the guix repo but I would be surprised if nobody has wrote a package for it yet. Am I missing something?
<brkwnds>I think it comes with mu by default. Not sure
<Guest19>ohh ok I think I had heard that is the case for some distros
<KarlJoad>Guest19: mu4e comes with the mu package.
<Guest19>ok nice
<KarlJoad>It is the case because they are developed by the same single person in the same repo, I think. They are built together.
<abcdw>KarlJoad: You can take a look at notmuch/mbsync/l2md setup here: Maybe you will find some parts interesting or inspirational.
<Guest19>is it proper terminology to say `the guix package repository`?
<civodul>Guest19: for packages we use the term "channel":
<jpoiret>there's no distinction between guix as a program and guix as a package repository
<jpoiret>It's all Guix
<nckx>It's best to avoid the term even if it's not incorrect, because people will interpret it incorrectly. Which sucks.
<mothacehe>KarlJoad: I'm using GNUS + nntp so that I do not download gigabytes of email locally
<civodul>nckx: which term?
<nckx>‘package repository’.
<civodul>ah yes
<KarlJoad>abcdw: Your stream about managing email with emacs is what introduced l2md for mailing lists to me. That is why I was curious.
<KarlJoad>mothacehe: I would like to avoid gigabytes, but I have a lot of storage too...
<mothacehe>nice thing is that you can use GNUS cloud to sync between multiple machines
<KarlJoad>mothacehe: That is pretty cool. Problem is I have not dug into GNUS at all, so that would end up being a rabbit hole for me.
<utkarshsingh>I'm testing a package definition locally, how can I command to re-build a derivation?
<jpoiret>you can do `guix gc -D /gnu/store/path` to delete a build output
<g_bor>Ok, so the second install was fine, but the pull got stuck
<nckx>Or use ‘guix build --check …’. But note that rebuilding the exact same derivation makes sense in only a very limited set of circumstances.
<nckx>utkarshsingh: ☝
<g_bor>Last line of output was computing guix derivation
<g_bor>On the second attempt it completed without a hiccup
<utkarshsingh>jpoiret: Thank you!
<utkarshsingh>nckx: Again thank you! And what about installing and re-installing them?
<jpoiret>installation in guix is stateless: you won't gain anything by reinstalling the same package
<jpoiret>ie, there are no hooks that change your system in any way
<g_bor>Is there a way we could get rid of hash guix after pull?
<nckx>If you used ‘guix install’, running ‘guix install’ again will replace the previous build with the current one. But same warning applies here too (as jpoiret is also typing): if the derivation didn't change, you might have wrong expectations about anything else changing.
<jpoiret>g_bor: needing to run `hash guix` is because shells often cache executable locations.
<nckx>g_bor: It's a permanent ‘suggestions [that don't make your eyes bleed] welcome’. ☺
<nckx>Technically, there is nothing stopping us from installing a custom PROMPT_COMMAND that hashes guix each time (assuming that works, I haven't actually tried it).
<nckx>Ethically, no.
<nckx>Or disable it for all shells just for guix, also quite heavy-handed.
<civodul>nckx: that PROMPT_COMMAND suggestion... why not?
<civodul>i view things differently now that i know CONDA runs "sudo ..." without telling you
<jpoiret>what is that arcane PROMPT_COMMAND?
<nckx>Evaluates arbitrary shell code, presumably in session scope, before printing each new prompt.
*nckx → dinner.
<jpoiret>but how would you set bash's own env variables from inside a forked process?
<civodul>jpoiret: you wouldn't; rather, could drop a file in /etc/profile.d that does that (for foreign distros)
<jpoiret>oh, right, I missed the "hash guix every time part"
<civodul>but yeah, i don't deny that this is debatable practice
<jpoiret>seems like a bad idea to me, given how PATH on Guix can be quite ... unusual
<g_bor>yup, it is too heavy that way...
<g_bor>and I also think we might end up in differences between shells
<g_bor>ok, I have checked the situation regarding guix home
<abcdw>civodul: Can you revert 9f371f23eb, please? Seems it's the reason for
<g_bor>now I have a different error after guix home reconfigure, but not the missing directory
<g_bor>it is saying: mkdir: Permission denied
<jpoiret>i remember someone reporting this issue also
<jpoiret>do you have /run/user/<UID>?
<jpoiret>is it owned by you?
<g_bor>I don't
<g_bor>this is a completely fresh install form 1.3.0, and after that a pull followed by home import and home reconfigure
<abcdw>g_bor: Yep, seems I already saw this issue, probably even made a PATCH for it. Do you have elogind enabled?
<g_bor>no, this is a just click through everything install
<g_bor>services is just network-manager, wpa-supplicant and %base/services
<abcdw>g_bor: `which loginctl`
<g_bor>nothing is found for that
<g_bor>elogind is pulled in if you install for eaxmple a desktop, but this is not the case here
<civodul>abcdw: i'm looking into
<abcdw>ok, you need to have elogind service in your system. Otherwise userspace shepherd and the rest of the Guix Home won't work.
<g_bor>I can pull it in manually if that is needed though
<nckx>Yes g_bor, elogind-service-type.
<g_bor>yup, I know that one.
<nckx>I don't know if it depends on having dbus-service too.
<g_bor>What I was not aware is that guix home depends on it
<nckx>g_bor: I read ‘I can’ as ‘can I’ ☺
<abcdw>g_bor: It seems relevant elogind requirement should be in the latest manual.
<g_bor>ok, let me quickly check
<g_bor>yup, my bad
<abcdw>civodul: Thank you!)
<g_bor>it is really there
<g_bor>so, basically what is needed is something that ensures we have the directory set up...
<abcdw>g_bor: No problem =) I didn't want to depend on elogind and XDG_RUNTIME_DIR, but shepherd, dbus doesn't work well without it, so I decided it would be a reasonable requirement for Guix Home.
<abcdw>g_bor: Yes, basically it's just a directory, which appears on first login and dissapears after complete logout.
<nckx>Hm, I'm weary to pull without authentication…
<g_bor>abcdw: can we extend the installer to give an easy elogind install, like it is offered for let's say ssh?
<g_bor>That would basically make this easier to get over this
<g_bor>I can send a patch to that effect, if you think this is a good idea
<abcdw>g_bor: Theoretically yes, but I don't use the installer and not aware of its capabilities, so better to ask someone, who is more into the topic of installer. Overall, the patch and a brief rationale looks like a good idea.
<g_bor>abcdw: ok, I will try to roll something out and send it for discussion
<abcdw>g_bor: Cool!)
<rekado_>re cgroups and the Hurd: the Hurd is flexible enough to allow for a cgroups-like feature (at least the parts that shepherd would need). Adding cgroups support to shepherd would not be blocked because the Hurd has no cgroups.
<KarlJoad>rekado_: Why would cgroup in shepherd not be blocked by Hurd not supporting them?
<jpoiret>abcdw: if all you need elogind for is to create XDG_RUNTIME_DIR, then I'm not sure it's a hard requirement
<jpoiret>shepherd works fine without elogind
<jpoiret>dbus should work ok, although polkit less so (but there might be ways to circumvent that, and they might already exist)
<jpoiret>mothacehe: i hope i'm not spamming the dump service too much. I'm pretty much done with the selective dump page, although it looks pretty ugly
<taxuswc>Hello! Sorry for a newbie question. I have guix installed on the top of a foreign distro. What is the proper way to make udev rules a from a package installed via guix (it's udisks) accessible to the host udev? It looks like udev looks into /etc/udev/rules.d and /usr/lib/udev/.. for its rules only..
<jpoiret>taxuswc: there's no proper way to do that
<jpoiret>one would be to symlink the ones in the packages you want into /etc/udev/rules.d
<jpoiret>but there are many tradeoffs here: if you symlink directly from the store, you'll have to manually update the symlink whenever you update the relevent package
<taxuswc>well, I thought about that, but with the new version of a package the symlink has to be recreated, which looks a bit inconvenient
<mothacehe>jpoiret: the more data we can get the better I think. Regarding the uglyness not a lot of people are supposed to see that page :p
<jpoiret>you could also symlink ~/.guix-profile/etc/udev/rules.d/, that would get updated along with packages, but that's not very good security-wise
<mothacehe>jpoiret: I had a couple of installer hard failure on real hw recently: no backtraces. Probably a segfault in guile-parted.
<mothacehe>we should see to enable coredumps
<jpoiret>I'd say that here you'd just be fighting an uphill battle to have distro-controlled things also have guix-controlled things. Not good
<jpoiret>mothacehe: but we wouldn't be able to catch them with the installer, right?
<jpoiret>about the ugliness: that was exactly the argument I had prepared :p
<jpoiret>Just need to add an page to confirm sending or not after the dump archive is created
<taxuswc>I know, unfortunately guixsd is not an option for me currently :(   (need some forbidden stuff for host repos) ..
<taxuswc>jpoiret: what are the security issues with symlinking the dir in the profile?
<jpoiret>maybe you could install the udev rules through your distro's package manager
<taxuswc>yeah, that's my current solution, I thought there is a better way but apparently no
<jpoiret>well, the .guix-profile symlink is controlled by your user, so you (or any program that runs as you) could modify it at anytime to introduce rogue udev rules. Remember that udev rules run as root, and now you've got a privilege-escalation :)
<mothacehe>jpoiret: great! the only way to upload that hypothetic coredump would be to check on the installer start if a coredump is already there and propose to upload it
<mothacehe>but it's probably way too complex
<taxuswc>it's a personal laptop, so probably that's not a very severe issue )
<jpoiret>the way I structured the new dump code would probably lead to good reuse on that point
<jpoiret>I don't think it would be more than 15 lines
<mothacehe>yeah we can discuss it later, uploading the Guile backtrace should cover most crashes.
<abcdw>jpoiret: Probably, elogind isn't a hard requirement, but Shepherd creates a socket in XDG_RUNTIME_DIR by default, also default (or mostly widespread and expected) path for dbus socket is XDG_RUNTIME_DIR/bus, some other apps also like to use /run/user/1000. It seems like an OK idea for Guix Home to rely on presence of elogind.
<jpoiret>you only need XDG_RUNTIME_DIR though, not elogind
<jpoiret>i bring that up because a surprising amount of people have expressed their wish of running an elogind-less system here
<gnoo>please don't
<gnoo>yes, making elogind or dbus as a requirement when it is not needed is bad
<gnoo>i still don't know why emacs is compiled with dubs support
<jpoiret>tbh, people who run elogind-less systems should expect things to just not work properly, but at least they know how to fix them or what's going wrong (I hope)
<gnoo>and, i really hope sway gets over the annoying habit of bailing out because xdg_runtime_dir is not set. it's _really_ annoying. just use /tmp dammit
<jpoiret>the XDG Base Dir spec ( says "If $XDG_RUNTIME_DIR is not set applications should fall back to a replacement directory with similar capabilities and print a warning message."
<gnoo>oh, then it's a bug with sway?
<jpoiret>the other side of the coin though, is that devs weren't using the XDG Base Dir before for many projects, but users kept bugging them about it so they finally added it
<jpoiret>well, yes, although SHOULD in a specification does not denote obligation
<gnoo>as an optional thing it's okay but requiring is a pain
<jpoiret>to put it another way, those programs could simply require an environment that follows XDG Base Dir
<jpoiret>to be frank though, XDG Base Dir is great, you just don't need elogind to implement it
<gnoo>i only agree with the base dir concept from xdg, and while it makes sense, systems should not stop working because an environment is not set which isn't really even needed to begin with
<taxuswc>there is also pam_rundir to silence sway's XDG_RUNTIME_DIR wails
<gnoo>pam and elogind was the reason i couldn't login in guix >_>
<gnoo>how do you know if something related to pam is running?
<gnoo>if pgrep pam shows nothing
<taxuswc>hmm I don't have elogind too, but the pam works fine (but it is from a foreign distro anyway)
<abcdw>jpoiret, gnoo, taxuswc: pam_rundir should work fine for Guix Home as well as elogind, systemd and whatever else. Can't say about all the apps, which are wrapped into home services or will be wrapped in the future.
<gnoo>shepherd does not require xdg_runtime_dir as far as i can tell
<gnoo>and well, can't you just use /tmp if it is unset???
<abcdw>gnoo: Shepherd relies on XDG_RUNTIME_DIR and fallbacks to /run/user/UID by default. But it of course possible to run it with a different socket path.
<taxuswc>jpoiret: (I forgot to say) thanks! I think I'll try to symlinking udev rules to root's profile for now and wander udev's docs a bit further
<abcdw>Thank you everyone for the chat. Going to sleep. Will see you in a bit.
<gnoo>how can i create a temporary user in guix?
<gnoo>well anyway, i don't really understand why it's in /run instead of /tmp. "security" i presume
<jpoiret>yes, /tmp has permissions issues
<gnoo>[me@antelope tmp]$ ls -lad "${XDG_RUNTIME_DIR}"
<gnoo>drwx------ 7 me users 4096 Jan 13 18:20 /tmp/me
<gnoo>seems simple to fix?
<gnoo>no need to depend on a directory only root can create a directory in
<gnoo>or (i presume) other setuid programs
<gnoo>setuid root*
<gnoo>and even then, what kind of threat model do people have that requires thinking, i better use a setuid program just to have a place that is more "secure" than /tmp
<gnoo>even sudo had a big vulnerability, i don't have the source at hand but i heard systemd gave root access to people with digits as the start of their usernames
<taxuswc>gnoo: xdg spec has a requirement that runtime dir *must* be removed on logout, so it looks like interaction with pam is inevitable?
<gnoo>(fixed in 241 or smth idk)
<ss2>oh good to know, but my digit's at the wrong end. :)
<gnoo>taxuswc: the must part does not matter when the whole part is optional. at least they got that right.
<gnoo>that part*
<gnoo>and even if it was a hard requirement, it's just a "spec". the gnu project breaks spec if that makes the lives of people easier. or at least that's what i got after reading it's coding standard.
<gnoo>anyway, enough rambling for today, i'm just tired a little. good day y'all
<apteryx>nckx: any clues as to what is needed to have unicode work as intended in the build container? I'm looking at the test failure of the password-store package
<apteryx>it is fonts?
<rekado_>KarlJoad: because we could make it work on Hurd.
<podiki[m]>I was just going to ask about password-store failure as well...
<rekado_>right now neither path exists. Shepherd doesn’t use cgroups. The Hurd doesn’t have cgroups.
<rekado_>both are things that can be implemented with some effort.
<rekado_>so it would be premature to cancel a development that hasn’t started just because some other development hasn’t been started.
<podiki[m]>apteryx: or maybe some env variable? like when you get garbage when TERM isn't set correctly
<podiki[m]>or wait, there was talk about tree update to 2, maybe something there needs to be set?
<mfg>did guix output get new colors? it seems more colorful then i remebered :D nice!
<podiki[m]>apteryx: rolling back tree to 1.8.0 fixes password-store build; besides just version and hash had to change back "PREFIX" to "prefix" in make-flags; I think it was noted here the other day that most other distros have not updated tree yet
<apteryx>it's probably something that changed in the unicode output of tree 2, as just this test fails
<podiki[m]>or some option that needs to be changed to match previous behavior
<podiki[m]>so just rollback version keeping other changes (cross compile and gexp)?
<apteryx>I'd prefer adjusting password-store if we find how
<podiki[m]>here is my diff that fixes the build problem at least
<podiki[m]>lunch time for me, but I can investigate later if you don't find it
<florhizome[m]>Good evening, guix!
<jacereda>I see commits of the form `* gnu/packages/embedded.scm (fc-host-tools)[arguments]<#:phases>...`, is that automated somehow? I can't see a snippet for that...
<jacereda>Also, I can't find where's the specification of that format is
<mfg>should be this:
***brkwnds` is now known as brkwnds
<apteryx>podiki[m]: tree 2.0.1 has uses json output automatically when the output is connected to fd 3, which the test harness of password-store does
<apteryx>(thanks to collegue olivier for debugging!)
<old>my pleasure!
<old>For reference, anyone ever heard of this weird feature (stddata = 3) for shell utilities?  It's the first time I've encountered this with `tree`.
<old>I've seen a thread on hacker news talking about it, but that's it
<jacereda>mfg: thanks!
<podiki[m]>apteryx: nice!
<florhizome[m]>i thought I read somewhere of a channel hosting recipes for older software (like old firefox), does somebody know which that is?
<lilyp>florhizome[m]: You're probably referring to Guix Past, but it's still following Guix guidelines so you get ancient Icecat
*civodul found this world-rebuild change on version-1.4.0:
<civodul>isn't it excessive?
<nckx>apteryx: I do not think it is Unicode- or font-related. Rather, the tree author seems to have invented/early-adopted a ‘fd 3 is for JSON’ meme? It's weird.
<civodul>i feel we run the risk of never converging, at least not in a timely fashion
<nckx>apteryx, old: … … :)
<nckx>Good morning/evening, Guix.
<nckx>apteryx, old: Also, thanks!
*vagrantc was disappointed to only get in about ~150 typo/spelling/guix lint description and synopsis fixes
<vagrantc>get intot he version 1.4 branch
<nckx>Any good song titles?
<lilyp>"Blocked by 53210"
<attila_lendvai>civodul, shouldn't that be done by reset-gzip-timestamp itself?
<civodul>attila_lendvai: i don't think so, i think it's better to keep procedures focused
<civodul>my point is more about questioning whether it's the right branch for this sort of change
<lfam>I did express some concern about the workflow
<lfam>I'm not sure if 1.3.0 was done in the same way or not
<attila_lendvai>i think this way it's twice the amount of stat calls, no? i'm getting impatient with guix performance, and started to keep an open eye for code that slows things down.
<lfam>But, despite my concerns, I think it's best to continue with the plan and save workflow discussions for after
*attila_lendvai tests something and will disappear
<lfam>But in general, for the future, I think that we should make releases in between core-updates cycles. Not immediately after them
<lfam>It seems like we make releases when the distro is at its most buggy
<attila_lendvai>yep, i was sprised about that, too (as a newcomer)
<vagrantc>some bugs only get shaken out when you try to make a release...
<lfam>Agreed vagrantc, but it's the same story with merging core-updates. So, why risk both sets of bugs?
<vagrantc>e.g. all the various "make dist" related bugs that i generally only look for when we're nearing a release
<attila_lendvai>e.g. qbittorrent seems to be broken in a non-trivial way after the c-u-f merge (
<vagrantc>actually, i had the forethought to look into "make dist" on core-updates this time around
<lfam>My impression is that Transmission gets more attention than qbittorrent on Guix
<lfam>At least, I pay attention to Transmission, but I've never used qbittorrent
<civodul>lfam: for 1.3.0 we certainly didn't do world rebuilds right after the core-updates merge
<lfam>I see
<civodul>i mean it's painful enough that you wouldn't want to do it twice in a row :-)
<lfam>Yeah. Well, it's largely a matter of motivation. Somebody has to lead the release, and if this is how they want to do it, we kinda have to let them do it this way
<civodul>yes, definitely
<apteryx>civodul: define excessive :-)
<lfam>But I've been waiting to start a big "branching" and "workflow" discussion until after 1.4.0 :)
<lfam>At least, the number-of-rebuilds cutoffs for the branches could be revisisted
<civodul>it would be great for important fixes like the Python and TeX Live fixes to not be held back by unrelated changes IMO
<civodul>apteryx: excessive in the sense that it'll require person-days or weeks of work
<lfam>As the build farm improves, we can make different choices about how to make big changes
<civodul>yes, ideally world-rebuild changes wouldn't take more time than the time to build things
<civodul>but in practice, we're not there yet
<civodul>there's always the occasional non-deterministic test failure
<civodul>or transient infrastructure issue
<lfam>Or lack of disk space
<apteryx>civodul: the changes I've squeezed in seemed relatively low risk (I've also rebuilt enough of the world to have it run on my system)
<florhizome[m]><lilyp> "florhizome: You're probably..." <- Yeah that’s great I wanted to try hyperbolas uxp stuff but I need ancient utils etc for that
<civodul>apteryx: i hope i'll be proved unduly pessimistic! :-)
<lfam>nckx: Any time to look at that SIMPLEDRM kernel config stuff?
<lfam>nckx: If not, I'll try just manually rewriting the configs later today
<nckx>Apologies, I thought you'd already fixed it (the ‘unset’ issue).
<nckx>That was unrelated?
<lfam>Hm, I didn't intend for it to be related
<lfam>I just noticed that while doing something else
<nckx>Then I made that leap in error. Sure, then, I'll pick it right back up.
<lfam>AFAICT, my typo fix commit didn't change the effective configuration. Basically, "unset" isn't understood by the kernel config machinery, so the default choice was taken. And the default was "N"
<nckx>Got it.
<lfam>Alright. No rush, I was just looking for something to do
*lfam g2g
<jgart>does this look like something that would need to be patched?
<jgart>xsel, xclip, etc...
<jgart>this is in effort to package gomuks. I have an issue open here in case anyone would like to work on it together:
<jgart>Send patches for other deps to ~whereiseveryone/
<jgart>We'll put gomuks in guixrus and then send a patch to upstream for review
<jgart>I have a module here for work on gomuks so far:
***lukedashjr is now known as luke-jr
<jgart>Hi Guixers! Does anyone have a preference for topics/tasks for Saturday's Documentation Meetup?
<vagrantc>documentation hasnever been my strong point, but i can provide a fairly guile-incompetant perspective and some native english speaker review :)
<jgart>cool! that would be helpful for sure
<nckx>vagrantc: What does that, anyway?
<vagrantc>and git push :)
<vagrantc>nckx: me spitting out numbers occasionally?
<nckx>Prove you're not a robot.
<jgart>rekado shared a very useful tip the yesterday on how to get patches off of
<jgart>essentially this:
<vagrantc>nckx: it's when i'm reading an irc channel, and think about switching to another channel and type the command to switch to that channel, and then finish reading and forget i already typed the command to switch to another irc channel
<jgart>`get-patch 48364 2`
<vagrantc>maybe i could write an irssi plugin to catch that.
<nckx>Aha :)
<nckx>You pathetic imperfection is proof sufficient.
<vagrantc>i am the imperfectionistist
<jgart>should I make the packages opaque instead of invisible until you hover over them?
<jgart>trying to brainstorm a design
<nckx>What's the goal?
<jgart>site get's built from guixrus channel by sourcehut ci when someone pushes a new commit to guixrus:
<jgart>Just to show all the current packages in guixrus
<singpolyma> Why not make it, like, a ul?
<jgart>here's the code for the website:
<nckx>If the point isn't to surprise users, then using mystery meat navigation is probably not best (although such meat is powerless against selecting all).
<nckx>jgart: Apart from that: cool!
<jgart>singpolyma, that's the capsul design currently. See gemini://
<jgart>I wanted the http site to be very different from the capsul
<jgart>nckx, thnx!
<nckx>What mean the colours?
<jgart>thanks dhruvin also and others who contributed
<singpolyma>jgart: reverse the order on http. Or random order. Very different!
<nckx>Ah :) Nothing, but also something.
<jgart>I have a friend who's going to contribute a modified Guix GNU logo with Toys "R" Us color gradients (yellow, red, blue, green, orange, etc...)
<jgart>singpolyma, how about commit order?
<jgart>not sure how I'll implement that yet though
<jgart>singpolyma, or maybe lexicographical order...
<singpolyma>Yeah, lexo and reverse lexo probably the two most useful
<jgart>or bloat order, most bloated to least bloated...
<jgart>ha jk
<jgart>or more cve security issues to least cve issues
<jgart>I'll have to let in simmer in my mind for a while
<jgart>patches are also welcome for the site. See
<florhizome[m]><singpolyma> " Why not make it, like, a ul?" <- ++ btw :D but you can always do that
<jgart>florhizome[m], if you'd like to send a patch for that feel free to. We can have different versions of the site on different branches and compare them
<florhizome[m]>tbh I have some more modules to submit before I’m gonna look into the channel design stuff more
<jgart>florhizome[m], I'll look at the pantheon stuff now again. Maybe we should make a todo for pantheon stuff so we can check it off the list
<florhizome[m]>they are ready to fly, can’t hold them back much longer
<florhizome[m]>* kinda worries he has developed some addiction to building packages
<jgart>I'm happy to help with pantheon stuff. Probably won't end up using it but I enjoy the packaging anyways ;)
<jgart>I have the elementary wallpapers as my desktop background with dwm as my wm hahah
<florhizome[m]>if you don’t mind, wayfire would be more important first so we can look at what freezes the build atm
<jgart>I've been using the elementary wallpapers for a while now
<jgart>florhizome[m], ok, I'll focus on that instead
<florhizome[m]>Well if you’re saying it, another sidequest would be a scraper for gnu artwork and put that on a channel so it’s more convenient to install.
<jgart>wallpaper/artwork as a package maybe
<jgart>it'd be cool to convert htdp to an info file like the sicp package we have
<jgart>not sure if the license allows that
<jonsger>hm, icedove on sway (wayland) freezes now pretty often. I think it was fine on Gnome (Xorg) which I used until two or three weeks ago. Do others have similar problems?
<florhizome[m]><jgart> "not sure if the license allows..." <- the Problem is more that they have different licenses i think
<Guest85>For some reason I cannot get my customized keyboard layout to be applied in xorg, though it works in a tty. I had it working just fine yesterday and the only thing I have changed in my config is installing more packages into the system profile. Has anyone dealt with something similar? Here is my configuration:
<florhizome[m]><jonsger> "hm, icedove on sway (wayland..." <- do you use icedove–wayland or set the environmental variable for Mozilla wayland stuff?
<florhizome[m]>I think MOZ_ENABLE_WAYLAND
<jonsger>using icedove-wayland
<jonsger>which is a wrapper including MOZ_ENABLE_WAYLAND=1 :)
<florhizome[m]>hm ok
<florhizome[m]>I run wayfire, didn’t have problems for now but I don’t use it frequently
<florhizome[m]><Guest85> "For some reason I cannot get..." <- I have had the problem since a while now that my keyboard config is not applied in xorg
<podiki[m]><florhizome[m]> "* kinda worries he has developed..." <- worried for myself too :)
***form_fee- is now known as form_feed