IRC channel logs

2021-06-09.log

back to list of logs

***dekenevs is now known as mitzman
<ixmpp>oh, /scripts is a reserved path for channels i guess
<raghavgururajan>Hmm.
<raghavgururajan>For this file https://0xacab.org/leap/bitmask-vpn/-/blob/0.21.2/pkg/config/version/genver/gen.go
<raghavgururajan>Doing `go generate pkg/config/version/genver/gen.go` on local git checkout, successfully generates version.go file.
<raghavgururajan>But if I do `(invoke "go" "generate" "pkg/config/version/genver/gen.go")` inside snippet in package-definition, I get this error: https://paste.debian.net/plain/1200472
<raghavgururajan>Thoughts?
<drakonis>the channel's asleep
<drakonis>but well
<drakonis>this is way out of my scope
<muradm>irc never sleeps..
***Kimapr9 is now known as Kimapr
<flatwhatson>raghavgururajan: "If a command is not found, the child process created to execute it returns a status of 127." - Bash Manual
<flatwhatson>missing go as an input maybe?
<ixmpp>muradm: neither does justice
<ixmpp>Request: operating-system (and home-environment) should have a slot for global package transformations
<drakonis>guix home isnt merged yet but soon
<ixmpp>Soon™
<marusich>hello
<vagrantc>efraim: i think your u-boot-sifive-unmatched target will want opensbi as an input, and specify OPENSBI= Yest. 20:51 Debian Bug Tracking ╰─►Bug#989579: Info received (Bug#989579: arm-trusted-firmware: Raspberry pi buil$
<vagrantc>oops
<vagrantc>efraim: that ws meant to be OPENSBI=.../fw_dynamic.bin
<vagrantc>efraim: oops, opensbi will need to install fw_*.bin also
<vagrantc>efraim: untested, but i should be in a position to test myself soon
***bandali_ is now known as bandali
***modula is now known as defaultxr
***MidAutumnMoon3 is now known as MidAutumnMoon
<ixmpp>Got pipewire on my system instead of pulseaudio now :) https://github.com/bqv/rc/blob/live/rc/home-services/pipewire.scm https://github.com/bqv/rc/blob/live/rc/packages/pipewire-next.scm
<mroh>good morning #guix!
<ixmpp>What gives, on the system* vs invoke thing
***taylan2 is now known as taylan
<ixmpp>Also, whats the status of guile-daemon?
<leoprikler>ixmpp: invoke properly raises an exception when system* fails
<ixmpp>Ah :)
<solene>hello Guix people
<solene>I need to create a string from elements generating in a loop, is it fine to accumulate data into a list to pass recursively (in the loop) and then apply a function on the result list to merge the list elements into one string?
<ixmpp>My interpretation of the mailing list is that lots of work was done on guile-daemon but only a tiny bit merged in, and nobody picked up the job (cause who would)
<flatwhatson>solene: seems fine, maybe you want string-join?
<solene>flatwhatson: string-join sounds the perfect function
<tissevert>hi guix
***o is now known as niko
***irfus is now known as Irfus
***Irfus is now known as irfus
<efraim>sneek: later tell vagrantc I wasn't really in a position to test it well. I assumed since it built it was fine. I'll look more at it later
<sneek>Got it.
<efraim>sneek: botsnack
<sneek>:)
***mitzman is now known as kitzman
<iung>Trying to install guix on btrfs flat layout. Had success with bios grub. Guessing that failure on efi system is not having /boot on separate subvolume.
<apapsch>If a package URL encodes both version number and a hash, should I set Guix version to version + hash?
<apapsch>Concrete URL is https://releases.shopware.com/sw6/install_v6.4.1.0_2951a105e0793ee8c3537b5987a938afdcb15002.zip
<cbaines>apapsch, the package version should just be the version
<leoprikler>you might also want to use git-fetch with https://github.com/shopware/platform
<zap>looks like python-cryptography and maybe some other python packages now require setuptools_rust... That requires rust cargo and potentially many rust packages...
<apapsch>cbaines, though if I hard code the hash in the package recipe, inherited packages cannot just specify another version
<apapsch>leoprikler: thanks, seems like the way to go. It'll introduce a few more build steps though
<cbaines>just specifying another version wouldn't work anyway, as the source would need to be changed accordingly
<apapsch>cbaines: assuming the URL in the source uses (string-append) with the version, should work if the URL had no other variable part?
<cbaines>apapsch, the sha256 value within the source will need changing if the version changes, which means the source will need changing as well
<apapsch>cbaines: i see, thanks
<cbaines>I'm also not sure exactly how the evaluation works for all the package record fields when it comes to inheritance
***Kimapr0 is now known as Kimapr
<minikN>Hello. I'm using emacs-exwm and have overwritten the definition to use emacs-native-comp instead of default 27.2 This is working thanks to irfus. Now I'm trying to start picom with emacs. My idea was to overwrite the install-xsession phase of the original package implementation to put "picom &" into the resulting exwm executable. This is my
<minikN>attempt: https://paste.debian.net/1200513/
<minikN>I thought I can just copy/paste it and add the lines I needed to the with-output-to-file function. But I'm now getting an error: ice-9/boot-9.scm:1685:16: In procedure raise-exception: error: synopsis: unbound variable.
<yoctocell>minikN: You have to add picom to the `inputs' field, otherwise it won't find the picom binary
<cbaines>yoctocell, it seems like minikN is expecting picom to be in the xhost input/package
<cbaines>minikN, even though you're inheriting the emacs-exwm record, because you're not setting a value for synopsis, that binding won't be available
<yoctocell>cbaines: doesn't it exist though? There is a `picom' package in (gnu packages compton)
<yoctocell>s/doesn't/does
<cbaines>minikN, you could add synopsis as a field to your package, or switch to using (package-synopsis emacs-exwm) in space of synopsis inside the arguments field
<cbaines>yoctocell, I don't know, I haven't checked
<yoctocell>the `substitute-keyword-arguments' form also looks a bit weird, I don't think it accepts keyword arguemnts
<yoctocell>oops, my bad, i missed a paren when reading ^^
<minikN>sorry yoctocell cbaines I was afk. I actually added picom as an input, althought the snippet doesnt show it. But the error is still the same.
<minikN>Sec I'll post an up to date one
<minikN> https://paste.debian.net/1200514/ This is how I have it atm. The error is still the same.
<minikN>with (define-module ...... #:use-module (gnu packages compton) .... ) at the top as well
<minikN>cbaines I'll try that.
<yoctocell>minikN: You are overriding the `inputs' for the original emacs-exwm, you should have something like this: https://paste.debian.net/1200517/
<yoctocell>and s/xhost/picom in (string-append (assoc-ref inputs "xhost") "/bin/picom") on line 36
<minikN>Ah damn, forgot to do that
<minikN>So atm I got this: https://paste.debian.net/1200519/ resulting in error: Invalid keyword: (substitute-keyword-arguments (package-arguments emacs-exwm) ((#:emacs emacs) (quasiquote (unquote emacs-native-comp))))
<pkill9>my immediate guess is that you need to add a variable to assign the keyword arguments to
<pkill9>i remember having to do that
<pkill9>I'm guix needs better error messages
<pkill9>s/i'm//
<minikN>pkill9 Could you give me an example? Sorry I just started with scheme a week ago or so
<irfus>is anybody using tectonic on guix as a complete replacement for texlive?
<irfus>I noticed a lot of updates to tectonic related packages in the latest pull --news
<pkill9>oh, nevermind, it's for when you want to re-use an existing keyword argument, such as appending configure flags
<pkill9>minikN: this is what i was thinking of https://paste.debian.net/plain/1200520
<pkill9>actually i found your issue, you need to put ,@ in front of the subistute-keyword-arguemnts functions
<pkill9>in order to splice them in
<minikN>You are correct
<minikN>But should I change the code according to the one in your paste?
<pkill9>I'm not sure what you're trying to do
<minikN>Now we're two.
<pkill9>only if you need to use the already-existing keyword used
<pkill9>otherwisejust add the ,@ in front of (substitute-keyword-arguments ...)
<pkill9>oh i think you may not need to use substitute-keyword-arguemtns at all
<minikN>Alright then I leave it as is. Is there a way to show build errors immediately with system reconfigure? I know for the build command there is --log-file
<minikN>I used it to replace ,emacs with ,emacs-native-comp. Because otherwise I'd always boot into 27.1
<pkill9>i think what you want to do is this
<pkill9>(arguments `(,@(package-arguments emacs-exwm) #:emacs emacs-native-comp #:phases ...)))
<minikN>I'll try
<pkill9>that will add in the existing package arguments, and replace emacs with emacs-native-comp i think
<abcdw>hi guix!
<abcdw>pineapples: I got everything I wanted with PipeWire: alsa, pulseaudio and screensharing. Draft implementation is here: https://git.sr.ht/~abcdw/rde/tree/master/item/rde/features/linux.scm#L72
<abcdw>Thank you for the help!
<minikN>pkill9 it starts building, but I'm getting build error now https://paste.debian.net/1200521/
<minikN>Wait I'll post the code again
<minikN> https://paste.debian.net/1200522/
<yoctocell>minikN: you should modify `%standard-phases', no `%install-xsession'. `%install-xesssion' should be a new phase that you add using (add-after 'build 'install-xsession ...)
<raghavgururajan>flatwhatson: Thanks! I am using go-build-system, so the go is already made available.
<minikN>Ah.. I forgot to change that back...
<raghavgururajan>I'll repost the issue.
<raghavgururajan>For this file https://0xacab.org/leap/bitmask-vpn/-/blob/0.21.2/pkg/config/version/genver/gen.go
<raghavgururajan>Doing `go generate pkg/config/version/genver/gen.go` on local git checkout, successfully generates version.go file.
<raghavgururajan>But if I do `(invoke "go" "generate" "pkg/config/version/genver/gen.go")` inside snippet in package-definition, I get this error: https://paste.debian.net/plain/1200472
<raghavgururajan>I am using go-build-system (so go is made available). Also git-minimal is in native-inputs to provide `git describe`.
<raghavgururajan>Thoughts?
<minikN>yoctocell @pk
<minikN>pkill9 cbaines yoctocell It's working now. Thanks for your help.
<yoctocell>minikN: you are welcome :)
<flatwhatson>raghavgururajan: 127 still means "not found". paste your snipped package definition?
<flatwhatson>:q
<flatwhatson>or do some experiment, like running (invoke "go" "--version") instead
<raghavgururajan>flatwhatson: I am confused on what's not found. Because when I tried it on git-checkout, I did so in pure-env with only go and git-minimal.
<raghavgururajan>flatwhatson: Here is the pack-def, https://paste.debian.net/1200525/
<flatwhatson>i think that snippet is perhaps not evaluated in the build environment
<raghavgururajan>flatwhatson: You were right. Same error for (invoke "go" "--version").
<flatwhatson>is there a reason that can't be moved to one of the build phases?
<raghavgururajan>flatwhatson: Same error with build-phases.
<flatwhatson>paste the new pkgdef please?
<raghavgururajan>just a sec
<raghavgururajan>flatwhatson: Ah, 128. https://paste.debian.net/1200526/
<raghavgururajan>Error: https://paste.debian.net/1200527/
<flatwhatson>well, i'm fairly sure that error is coming from "go" now :)
<flatwhatson>can you keep the failed build environment, enter the build directory, source the environment, and try it by hand?
<flatwhatson>you might be able to convince go to be more verbose, or experiment with the command in the proper context
<raghavgururajan>You mean manually generate?
<raghavgururajan>Should try it in pure-env?
<flatwhatson>i think the env file in the build directory gives you a pure env anyway
<flatwhatson>you should see PATH there containing only build deps
<raghavgururajan>flatwhatson: https://paste.debian.net/plain/1200528
*raghavgururajan looks how to make go more verbose
<flatwhatson>cd /tmp/guix-build-bitmask-0.21.2.drv-0; bash; source environment-variables; ...
<flatwhatson>that will adopt the *actual* build environment. the bash call is to avoid polluting your main shell
<raghavgururajan>I see.
<raghavgururajan>flatwhatson: https://paste.debian.net/plain/1200533
<raghavgururajan>Thats all I could make go do.
<raghavgururajan>Only 3 options are available. -n -v -x
<raghavgururajan>It seems the git command in main.go is the culprit.
<flatwhatson>oh, that might do it. at this point we're not in a git checkout anymore, the sources get copied to the build directory
<flatwhatson>that might be a reason to run it as a snippet like you originally had...
<raghavgururajan>Was just thinking the same
<raghavgururajan>Yeah
<raghavgururajan>flatwhatson: So I might have to use absolute path to go binary right?
<flatwhatson>raghavgururajan: i think you need (patch-inputs (cons `("go" ,go) ((@@ (guix packages) %standard-patch-inputs))))
<raghavgururajan>flatwhatson: Inside snippet?
<flatwhatson>next to it in source definition
*raghavgururajan tries
<raghavgururajan>error: go: unbound variable
<flatwhatson>(use-modules (gnu packages golang))
<raghavgururajan>That's already there though.
<raghavgururajan>flatwhatson: https://paste.debian.net/plain/1200539
<flatwhatson>hmm, when you say it's already there, do you mean you already have it imported at the top of this scheme file? we need to directly reference the go package here
<rictjo>Hi everyone. I hate asking potentially noob questions but I need some help...
***Server sets mode: +Ccntz
<ecbrown>rictjo: not on a repurposed macbook and not on a radeon 580
<ecbrown>i pulled the card and just use integrated graphics. it's fine
<rictjo>Ok... and how would I do that :^D
<ecbrown>what is the form factor of your computer?
<rictjo>the computer is purely AMD
<rictjo>so there is no integrated graphics on the CPU
<ecbrown>uh oh
<ecbrown>imo from a libre perspective you are sol but that's my limited experience
<rictjo>sol?
<ecbrown>out of luck
<rictjo>ah
<ecbrown>guess that doesn't come across so well in lowercase ;-)
<rictjo>so there are basically no GPU cards that will work if one wants to run libre AMD system
***zimoun` is now known as zimoun
***Kimapr7 is now known as Kimapr
***jpoiret1 is now known as jpoiret
***iyzsong- is now known as iyzsong
***dongcarl7 is now known as dongcarl
<ecbrown>rictjo: a universal problem rather than a guix one. you may want to look at some of the libre hardware pages. also i don't know if it's kosher to recommend looking into wheter intel sells something that runs libre
<rictjo>the combo AMD CPU and NVIDIA + nouveau works well enough
<dstolfa>don't new AMD GPUs work fine under libre?
<ecbrown>yes, it's pretty solid. damned expensive
<rictjo>?
<rictjo>I only saw support for rx 580
<rictjo>it finds it
<rictjo> VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev e7)
<ecbrown>i was saying nvidia is expensive.
<rictjo>and pushes in the amdgpu kernel driver
<dstolfa>my experience with nouveau is not great
<rictjo>but there is still an error from it trying to load in some additional firmware
<dstolfa>especially on wayland
<dstolfa>instead of using the nvidia gpu i have, i just turned it off and use the integrated intel gpu
<rictjo>yeah I don't use wayland
<dstolfa>that works well
<rictjo>I run i3
<rictjo>and regular X
<dstolfa>yeah fair, i can't really use xorg because i have multiple screens with different resolutions and need per-screen hidpi scaling that doesn't break every time i turn my screen off
<rictjo>but I find it strange... everything kind of works... its just the last step of pushing in or loading the firmware part that fails... the amdgpu kernel module is loaded well enough
<dstolfa>rictjo: well, libre doesn't allow any non-free firmware to be loaded
<dstolfa>so that's kind of expected if the firmware is non-free
<rictjo>yupp I think that is the issue
*ecbrown mulls popping the rx580 back in and testing
<rictjo>still strange that the rx 580 is listed as working free gpu hardware on: "https://h-node.org/videocards/catalogue/en/1/1/undef/undef/undef/undef/video-card-works/undef?search_string=Radeon+RX+580&submit=Search"
<ecbrown>rictjo: the $100 solution is to get an nvidea i think
<rictjo>using the free nouveau driver then vulkan hacking in C++ won't fly
<rictjo>which is why I tried the rx 580
<rictjo>how long will it take for someone in here to say I have to use the nonguix channel :D
<ecbrown>did you try adding the nomodeset nosplash stuff?
***Tirifto_ is now known as Tiriftoj
<rictjo>...
<rictjo>no
<rictjo>thanks for that
***Tiriftoj is now known as Tirifto
<ecbrown>it might be worth one more runthrough to see if it will pop into GNOME mode and not get hung up on mere console stuff
<ecbrown>(right those are added to GRUB parameters)
<rictjo>it should be done automatically no? but I'll try and manually edit the grub entry prior to next boot
***bdju_ is now known as bdju
<raghavgururajan>flatwhatson: Yeah, I meant at the top of file. Did you mean like this (https://paste.debian.net/plain/1200552)?
<flatwhatson>raghavgururajan: no, it should just be a normal import at the top of the file. weird that it wouldn't be visible at that patch-inputs :/
<raghavgururajan>hmm.
<apteryx>hmm, is the 'org.gnome.desktop.interface' D-Bus interface provided by GNOME itself?
<apteryx>'peek' appears to have a hard dependency on it
<apteryx>(peek:11298): GLib-GIO-ERROR **: 10:45:45.054: Settings schema 'org.gnome.desktop.interface' is not installed\nTrace/breakpoint trap
<zap>wow! I just did `guix import crate -r pyo3` (10 packages) and pased it to guix and it just built the thing! Is it normal for crates? Or im just lucky?
<zap>uh.. tests failed tho
<pineapples>abcdw: Pleased to read that! You are welcome :) Anyways, I have a question regarding the draft implementation — more precisely: `dbus-home'; namely, is a session bus instance of D-Bus spawned by guix home resuable across a number of home services?
<pineapples>s/resuable/shared
<ix>abcdw is not present
<ix>But huh, guess he beat me to it then
<ix>I'll have to merge my my implementation with his
<pineapples>Hopefully, I'll have sneek, the bot, forward this message to them when they're back online
<ix>This config is very interesting
<pineapples>ix: Keep in mind that that Guile module that they shared a link to requires `guix home'
<ix>pineapples: i already depend on guix home :p didnt you see my links?
<pineapples>Oh, I did not
<ix>I cant be bothered to wait for stuff to be upstreamed, its perfectly usable
<ix>I think i'll do it differently
<ix>I was intrigued by the "features" concept
<ix>But not sure i wanna go that route
<ix>Christ what is up with libera
<rictjo>on the nomodeset nosplash suggestion it resulted in a new error for amdgpu kernel driver
<rictjo>this time saying that VGACON disables amdgpu kernel
***dekenevs is now known as kitzman
***MidAutumnMoon3 is now known as MidAutumnMoon
***smartin1 is now known as smartin
***sneek_ is now known as sneek
***ecbrown` is now known as ecbrown
<ecbrown>rictjo: yeah... i've been down this path before. i think this is why i just pulled the card
<ecbrown>now it is a wicked headless vnc server
<raghavgururajan>apteryx: 'org.gnome.desktop.interface' is provided by the package `gsettings-desktop-schemas`.
<raghavgururajan>leoprikler: You around?
<leoprikler>what's up?
<raghavgururajan>leoprikler: When we were working on Telegram stuff, we shortly pondered the use of `@` inside snippet, to refer to inputs. Do you know how to do that?
<flatwhatson>the problem is that "go generate" needs to run inside a git checkout. running as a build phase is too late, it's just a copy in the build directory. maybe snippets run in the git checkout?
<leoprikler>well, I don't exactly know how to apply it to inputs, but (@ (module spec) variable) should work if (module spec) exists in the context of the snippet
<flatwhatson>if so, we need to augment the patch-inputs with "go", so the snippet can run "go generate"
<flatwhatson>i suggested a terrible hack: (patch-inputs (cons `("go" ,go) ((@@ (guix packages) %standard-patch-inputs))))
<raghavgururajan>In this (https://paste.debian.net/1200563/), I would like to use something equivalent to `(string-append (assoc-ref %build-inputs "go") "/bin/go")`.
<raghavgururajan>leoprikler, ^
<leoprikler>I don't think you should do that in a snippet
<raghavgururajan>leoprikler: That exact line or not event the technique of referring to inputs?
<leoprikler>That exact line, you shouldn't invoke Go during a snippet
<leoprikler>although tbh I don't see the appeal of using inputs in snippets now that I think of it
<leoprikler>maybe native-input sed in some super awkward cases, but yeah
<raghavgururajan>Oh. I don't see any other way to generate version file.
<raghavgururajan>May be add the file as patch?
<pineapples>raghavgururajan: Not to nag you about this while it is still work-in-progress, but that huge Telegram release, which I briefied you about weeks ago, might be out within the upcoming few weeks. I don't know when is the next core-updates merge, but whatever you do now might be invalided by it
<raghavgururajan>pineapples: Thanks for the heads-up. I am not working on telegram though.
<raghavgururajan>:)
*raghavgururajan is working on Bitmask (https://bitmask.net)
<leoprikler>raghavgururajan: do you need to generate the version file in a snippet though?
<leoprikler>how about after unpack?
<pineapples>I see. I mistakenly assumed that you were working on it when I saw that you mentioned it. Sorry about the confusion
<raghavgururajan>leoprikler: I think so. After unpack, the dir no longer git-checkout. So `git describe` won't work.
<karthik[m]>raghavgururajan: ping!
<raghavgururajan>No worries pineapples.
<raghavgururajan>karthik[m]: Hey o/
<raghavgururajan>leoprikler: https://0xacab.org/leap/bitmask-vpn/-/tree/0.21.2/pkg/config/version/genver
<raghavgururajan>It generates `version.go` file under 'pkg/config/version'.
<raghavgururajan>That version.go file is then imported by various other go files.
<leoprikler>hmm, how about creating your own version.go from the version info in Guix?
<raghavgururajan>*gets imported
<raghavgururajan>Is that possible?
<raghavgururajan>How though?
<leoprikler>call-with-output-port exists, just write Go code :P
<raghavgururajan>I could generate version.go file in local git checkout of bitmask-vpn and then use that as patch.
<leoprikler>I'm p sure you don't need all of the git info
<leoprikler>just commit will likely be enough and you can probably fake it
<mroh>you could maybe also try to do that (go)template substitution in main.go yourself in scheme and substitute that template call code away...
<raghavgururajan>Hmm.
<raghavgururajan>flatwhatson, leoprikler, mroh: https://paste.debian.net/plain/1200573 :D
<leoprikler>that looks a little too complicated
<leoprikler>why not simply delete the file and write the version.go two-liner?
<raghavgururajan>leoprikler: So we have a macro to create file?
<raghavgururajan>*Do we
<leoprikler>call-with-output-port is a function that exists
<leoprikler>or rather call-with-output-file
<raghavgururajan>Oh I thought that was a joke lol
<ruffni>should patches adding packages be split on a per package basis? i have a package depending on two other packages -- but they are not defined publicly. does a patch with a non-public define even make sense?
<ixmpp> https://patches.guix-patches.cbaines.net/project/guix-patches/patch/dvQW5QOoMhwaIXz7zMjE5FemgwPRLjI5ygh4wgbnFN2zo3gBq0-FrBzSeS78AnUQbLTcCyyMeywb5DGDy4AcGA==@fron.io/
<ixmpp>leoprikler: iirc you were ok with this^
<leoprikler>I haven't looked at the patch itself yet
<leoprikler>does this package do anything useful or is it just there as an input?
<leoprikler>[I am in principle okay with having a systemd package in freedesktop.scm though]
<ixmpp>Just an input
<ixmpp>No real use for it on a binary level, since we use shepherd
<ixmpp>But lots of things link against it so yeah
<leoprikler>I don't think that alone justifies a package though
<leoprikler>If we have a systemd package, it should be usable
<ixmpp>As init?
<ixmpp>Meh i'll shove it in nonguix instead...
<leoprikler>well perhaps not as init, but in some capacity
<leoprikler>e.g. similar to user shepherd
<leoprikler>we do have elogind to replace logind for example
<leoprikler>IIRC you want to link some naughty software against it, but have you tried patchelfing that out?
<ixmpp>The program responds very badly (SIGILL or SEGV) to not being in it's original stable state, but maybe i'll try it...
<Noisytoot>ixmpp, Don't put systemd in nonguix, because it's free, and that means that if I want systemd, I need to enable a channel with other proprietary software I don't want
<ixmpp>Noisytoot; well i did try and put it in here
<ixmpp>but supposedly not wanted
<ixmpp>the patch is up there if you want to accept it
<drakonis>Eh
<drakonis>What do you mean not wanted
<ixmpp><leoprikler> I don't think that alone justifies a package though
<drakonis><leoprikler> [I am in principle okay with having a systemd package in freedesktop.scm though]
<drakonis>Right before
<ixmpp>so what's the verdict here
<ixmpp>leoprikler; is it going in or not?
<dstolfa_>drakonis: i think the argument was that using an external, non-free piece of software and *nothing else* doesn't justify putting a package of systemd's complexity into guix that would need to be maintained and adhere to quality requirements
<dstolfa_>at least that's how i understood it
***dstolfa_ is now known as dstolfa
<drakonis>Ah, sure.
<dstolfa>this is why a contrib repo would be nice
<drakonis>Aye
<dstolfa>basically, FSDG-compliant stuff that doesn't necessarily meet the quality standards of Guix
<Noisytoot>free but terrible software
<dstolfa>i think "terrible" is unfair. i mean more along the lines that the way it's integrated into guix isn't up to standards quite yet, so it's in contrib
<dstolfa>though i think systemd would always live in contrib because it seems like it would be very difficult to cleanly integrate systemd into guix since shepherd is already there as the actual init, this would be a user thing which i imagine wouldn't be the most well-integrated thing
<dstolfa>basically, contrib would remove "fully integrated solution" expectations
<dstolfa>but we should always strive to bring things from contrib into master
<drakonis>It's free but it really doesn't meet the standards for inclusion on the main repository, ie: bootstrapping is very difficult
<drakonis>Contrib should be home to services that don't match the expected level of quality either
<drakonis>Pretty much the slapped together stuff
<drakonis>And in nixos, there wasn't a lack of these
<drakonis>The highly trivial stuff, that is
<leoprikler>ixmpp: it'll probably go in after some review and perhaps adjustments
<drakonis>civodul: what are your thoughts on the creation of a contrib channel?
<leoprikler>IIRC people already publish their own "contrib" style packages on gitlab, sr.ht etc.
<drakonis>yeah
<drakonis>basically, coalesce all of those into a single place
<drakonis>home to packages and services that cannot be available on the main channel due to being non trivial to bring to the standards required for it
<drakonis>extremely non trivial
<drakonis>guix-science is one i've been using for Rstudio
<leoprikler>I think the federated nature of extra Guix channels is a good thing, not a bad one.
<drakonis>i suppose there will be people who'll complain
<leoprikler>There's probably an "awesome list" listing a bunch of those too
<ixmpp>indeed, that's a major reason why i keep my config/channel public
<drakonis>but the real kicker here is to offer a substitutes server for these definitions
<ixmpp>following the same ethos i had with nixos flakes
<drakonis>i don't think there's one for guix yet
<ixmpp>drakonis; this is one reason why i'm extremely keen to see ipfs support
<ixmpp>then we're all substitute servers
<leoprikler>I've seen one advertised on the MLs, so there's at least one.
<ixmpp>leoprikler; cool :)
<drakonis>oh, leo leboutier ran one before he left
<leoprikler>Okay, I may need to correct myself, there was one
<drakonis> https://sr.ht/~lle-bout/awesome-guix/
<drakonis>rip
<sarg>hey, may I ask for a review/merge of this package http://issues.guix.gnu.org/48909 ?
<drakonis>this isnt going to get updated anytime soon, sadly.
<drakonis>guix-past is one i was looking for
<drakonis>oh, hey, ufrgs has packages on guix-hpc, neat.
<dstolfa>leoprikler: i think there is value in a contrib channel that is official rather than scattered, namely that it gives a direct upstreaming effort that is gradual and doesn't require a lot of local maintenance beforehand
<dstolfa>contrib would be a step up from random channels online
<dstolfa>but it wouldn't quite meet the guix requirements
<leoprikler>that's true, but there are imo two reasons to keep a rando channel:
<drakonis>they're not mutually exclusive concepts anyways
<leoprikler>1. To have stuff, that can't fit Guix anyway.
<leoprikler>2. To have stuff, that can fit Guix, but isn't yet upstreamed.
<dstolfa>yeah, contrib would be more for (2) that has some significant work in progress that others may want to contribute to
<ixmpp>or just use
<dstolfa>and contrib would also avoid someone having to enable some channel that contains non-free software and would meet FSDG
<drakonis>yes.
<pkill9>we also have s6 service manager
<pkill9>which could be used as init i think but isnt
<ixmpp>s6 doesn't have to be run as init, in fairness
<leoprikler>The WIP stuff for Guix should sooner or later land in the MLs, otherwise it's pointless.
<ixmpp>it can be used as not PID1
<pkill9>can systemd be run as not init?
<drakonis>it can
<ixmpp>no
<drakonis>it does complain about not being pid1 though
<ixmpp>wait, really?
<drakonis>yeah
<ixmpp>even if PID1 itself isn't systemd?
<dstolfa>leoprikler: maybe, but contrib gives you a way to get users to actively test it, report things and help push things in the right direction (and avoids risking non-free software creeping up in the system)
<leoprikler>systemd can be run as user process, but I'm not sure if it wants to run as PID1 as well
<dstolfa>i explicitly don't enable any third party channels because i don't want non-free software on my system
<drakonis>i've run into that once when i ran wsl2 on windows
<drakonis>you cant use it to manage services
<ixmpp>interesting.
<leoprikler>dstolfa sure, but you can fetch the same patches from mumi
<drakonis>it still runs at limited capabilities
<leoprikler>or use a channel, that is not the bad channel, that explicitly states it only has free software pending guix inclusion
<dstolfa>how would one find these and trust them though?
<dstolfa>you see a random repository on gitlab/github/whatever that claims to do it, but isn't guix itself
<leoprikler>any effort from Guix contributors to make sure your freedom is being respected by some contrib channel is better spent reviewing actual patches on the MLs
<dstolfa>the level of assurance you'd get from guix/contrib is still way higher than you would from (url "https://github.com/randomuser/randomchannel")
<ixmpp>on the one hand, i agree with leoprikler, i like more federation, but i feel like the others have a point in that a contrib channel *would* encourage me to contribute more because it lowers the barrier to entry
<leoprikler>the entry barrier to the ML is super low
<vagrantc>dstolfa: well, you're talking about a signed repository, right? so use signatures from reputable sources.
<sneek>Welcome back vagrantc, you have 1 message!
<sneek>vagrantc, efraim says: I wasn't really in a position to test it well. I assumed since it built it was fine. I'll look more at it later
<leoprikler>it's literally one spam filter, nothing more
<ixmpp>leoprikler; that's the barrier to entry to submitting the patch, not to having it merged :p
<drakonis>also people are just weird about contributing to the project
<leoprikler>submitting the patch is all it takes to make people aware of it
<vagrantc>efraim: yeah, thanks for updating u-boot-2021.07 :) I'll try to test on the unmatched soon (should have it toda
<vagrantc>y
<leoprikler>the ML is public, everyone can stitch together their guix from master + cherry-picked ML stuff
<vagrantc>efraim: though not sure when i *should* have time for it vs. when i will work on it :)
<ixmpp>if the end result is going to me me submitting a patch that sits in the archive gathering dust, i'm just not going to submit the patch
<ixmpp>that's what i mean by it's incentive
<ixmpp>if i contribute it to a contrib channel, at least it's there, and it's used, it's not just in a big ol' mbox file somewhere
<dstolfa>leoprikler: that is a lot of effort for testing
<dstolfa>testing changes should be easy for those that wish to do so, not asking them to manually merge patches
<ixmpp>also yeah that use case seems insane
<ixmpp>how do you maintain cherry-picked ML stuff?
<leoprikler>git rebase?
<dstolfa>that's.. a lot of work
<ixmpp>and then send it to the ML again?
<leoprikler>nah, you just keep it locally
<ixmpp>congrats you invented version-control-by-email
<leoprikler>it's already in the ML, someone will look at it eventually
<leoprikler>if not, just follow up the bug thread and bring it to people's attention
<leoprikler>If something changed significantly, send v2
<dstolfa>i don't see most regular users (which are the ones you really want testing your software because they will find usability issues and breakages as a result) going to mailing lists and cherry picking patches for their locally maintained patchset of guix
*vagrantc doesn't see how cherry-picking patches is any harder that maintaining an entire git repository infrastructure
<dstolfa>vagrantc: because it has to be done by everyone, manually
<ixmpp>ok, i'm seeing the need for a contrib channel more and more now
<leoprikler>It usually doesn't though?
<leoprikler>The need for a contrib channel is extremely exaggerated here
<dstolfa>leoprikler: adding a contrib channel that can be copy pasted from official documentation is far easier than doing a git clone, build, getting mbox files, git am, making sure they don't have merge conflicts and then maintaining that build locally
<vagrantc>here's the other thing, if you want to maintain a contrib channel ... maintain a contrib channel and publicise it.
<drakonis>hmm, well...
<vagrantc>to do it right is going to take work, if you want it, do the work :)
<vagrantc>and work together on it ... and *demonstrate* that it's useful to the community
<drakonis>aight, let's try something real quick
<leoprikler>dstolfa: you already have that local checkout if you're working on Guix and you already have your patch sitting on top of master
<dstolfa>leoprikler: yes, if you're working on guix. what about people who aren't and simply wish to be testers and report issues they find?
<drakonis>slice nonguix into two halves, the parts that are up to no good, ie: nonfree and then the contrib side
<drakonis>let's see how this works out
<dstolfa>also, i'm not saying anyone here should do the work. i'm simply wondering if this is something that guix as a project would consider
<dstolfa>because if so, then it *is* worth doing the work
<leoprikler>the channel you're mentioning is explicitly about containing patches, that fall into category 1
<dstolfa>otherwise a third-party contrib channel is as good as any other channel
<drakonis>sure
<leoprikler>Every channel is a third-party contrib channel :P
<leoprikler>also I'm p sure that testers are acquainted with our git am workflow.
<leoprikler>How do testers test other software? "Use the flatpak, lol"?
<dstolfa>well, in debian they just enable the contrib repository
<dstolfa>or the testing repository
<dstolfa>in freebsd, they just run latest, which is a 1 word config change
<ixmpp>can you imagine debian without the testing repository
<ixmpp>that would be a death sentence
<dstolfa>this makes testing easy for regular users who just wish to get on with their lives and report bugs as they find them
<leoprikler>guix master is the same as debian testing or freebsd latest though
<leoprikler>you want something that is later than latest
<Guest4>Hello #guix.
<Guest4>:)
<dstolfa>leoprikler: well yes, because guix is not the same thing as debian or freebsd. it has a whole set of guarantees that are offered by guix master that could require a significant amount of work for some packages (e.g. systemd)
<vagrantc>the contrib stuff in debian is closer to non-free, as it may depend on non-free toolchains
<Guest4>I have a question.
<vagrantc>Guest4: go for it!
<leoprikler>Go ahead and ask, we don't bite (badly)
<Guest4>I tried to install the Guix package manager on my Fedora 34 pc.
*dstolfa just had 2 burgers so he can't really bite anything even if he wanted to
<Guest4>But when I want to run $ guix install hello I get the following error:
<Guest4>guix system: error: failed to connect to `/usr/local/var/guix/daemon-socket/socket': No such file or directory
<drakonis>leoprikler: you forgot 3: packages that are inviable to ever meet the standards proposed by guix and are free software
<Guest4>Do you have any ideas how to fix this?
<dstolfa>Guest4: it sounds like the guix daemon is not running, can you check with ps?
<Guest4>Also it's "guix install error …" and not "guix system error"
<drakonis>Certain proglangs with notably complex bootstrapping long tails
<drakonis>Dotnet, Scala and other jvm langs
<leoprikler>Those are category 1 according to my definition, but yeah, category 1 has subcategories 1a non-free stuff and 1b dependency hells.
<drakonis>CLR langs
<Guest4>dstolfa, yes it's not
<Guest4>running
<leoprikler>Guest4 /usr/local/var is bogus, is this a local checkout?
<Guest4>I ran the install script
<leoprikler>if so, try ./configure --localstatedir=/var
<leoprikler>hum, the install script produces that?
<Guest4>Yes.
<Guest4>I ran it serveral times with SELinux enforcing and also set to permissive.
<Guest4>(Because I also got several SELinux errors)
<Guest4>errors := alerts
<Guest4>Oh wait it still seems to be enforcing.
<leoprikler>not sure if I have the correct install script, but mine only references /usr/local/share/info and /usr/local/bin
<bdax>out of interest, why does the guix source tree include nix? does guix use nix?
<Guest4>Ah, now it's working! :-D
<Guest4>Thanks for your help!
<vagrantc>bdax: guix-daemon is currently a fork of nix-daemon ... not sure much else is used
<leoprikler>np and have a nice day
<Guest4>Thanks, you too. :-)
<solene>I'm quite happy, my firewall service is kinda working!! https://pastebin.com/HRF3YEET
<bdax>oh interesting, thanks vagrantc
<ecbrown>solene: very nice. question: is that a firewall dsl?
<ecbrown>(i have used nftables/iptables service types)
<solene>ecbrown: it's only iptables behind
<solene>not sure if I should integrate it into iptable service, they are curently incompatible
<solene>when using this firewall-service, it sets DROP for everything on input and will allow tcp and udp ports listed, it's easy and effective
<ecbrown>well, i just submitted a patch for iptables that tries to give `ufw allow ssh' semantics
<ecbrown>my point being, if you are looking at firewall stuff, the document's recommended iptables needs some love i think :-)
<ecbrown>the connection being, i think your configuration looks like that, simple allow ports
<ixmpp>roptat; why are you not in the other channel, by the way?
<ixmpp>i see you're a project member!
<roptat>I'm not following that very closely tbh
<ixmpp>hmm
<roptat>I'm an honorary project member :p
<solene>ecbrown: I'll continue to work on this a bit, I think the code is not very good looking at the moment, I'll write to the mailing list for advices
<ixmpp>ha
<solene>my point is that nobody wants to have fun with iptables rules, most of the time we only want to block incoming traffic except for a few ports
<roptat>(I contributed a few things at the beginning, but haven't done anything since then)
<roptat>you mean there's an IRC channel? I didn't even know ^^
<solene>a guix fight club? :O
<ecbrown>solene: yeah
<zap>solene: haha
<drakonis>yes...
<drakonis>the fight club!
<solene>I've sent my code and questions to guix-devel mailing list :)
<nckx>Greetings → Guix.
<dstolfa>\o
<drakonis>greetings friend
<ryanprior[m]>hi =D
<drakonis>leoprikler: tbf, what is the cost of letting people collaborate on a contrib channel that's optionally available out of the box?
<drakonis>every often, something can be fished out of contrib once it is deemed it meets the bar for mainline
<nckx>How would this channel relate to Guix proper?
<dstolfa>ah, we are back on this discussion
*nckx waves back.
<drakonis>in that it provides a home for packages that don't quite meet the standards for guix proper but still meet the fsdg
<dstolfa>nckx: i think the way i see it is that this would be services and packages that aren't yet ready for mainline inclusion because of quality concerns, complexity in bootstrap, etc. it would be in official documentation, it doesn't have to have binary packages at the start at all. it would just be another "branch" if you will.
<nckx>If people here feel this has been discussed to death I won't push on, I just logged in for the day.
<drakonis>as well as services for that
<dstolfa>it would be 100% free software, FSDG-compliant
<dstolfa>nothing non-free and nothing that depends on non-free toolchains
<drakonis>i think it ended being brushed away for the wrong reasons
<dstolfa>the idea would be that you can then add a channel in your channels.scm which is called guix/contrib or something along those lines, and it would pull changes from there too
<drakonis>the primary value of such a thing is that it can definitely improve guix's user accesibility and provide the means to do quality control on the main repository
<drakonis>nix itself has been for the longest a victim of having no split between the good stuff and the crappy stuff
<nckx>On person's ‘brushed away’ is another's ‘omg please stop’. Just a general point, I really don't know or care enough yet to take sides if there even are any.
<drakonis>hmm, sure.
<yoctocell>this sounds very much like nix nur https://github.com/nix-community/NUR
<nckx>The latter person isn't necessarily right.
<drakonis>NUR is the equivalent of channels i suppose
<drakonis>since all it does is cobble a bunch of disparate channels under an umbrella
<yoctocell>everyone has their own repo with packages and services, and they all get collected into a big repo that everyone can pull
<drakonis>nckx: i will not poke too much then
<dstolfa>i don't think there are sides. i don't personally need anything like this, but would be willing to help put this together. however, i would first like to get an idea of if this would be of any interest to begin with
<raghavgururajan>Anyone know what 'goshim' is and where to obtain it for `libgoshim.h` and `libgoshim.a`?
<raghavgururajan>Web wasn't helpful.
<drakonis>nixpkgs has a significant amount of terribly written packages and modules that would be best served in a different directory perhaps
<drakonis>but isnt because nixpkgs is structured in a way that isnt very conductive to that
<dstolfa>i think it is also a complete waste of time to make a guix/contrib channel if it won't be official, as it has the same amount of trustworthiness as any other random repository that's not under the guix umbrella
<nckx>Who maintains the channel, and is everyone working on Guix expected not to break it? I guess I see a spectrum between ‘more work (maintaining self-confessed shit packages, yay…) for people working on Guix’ and ‘don't worry, it's totally separate’ but then will users grok this if it's promoted by the installer/name/whatever.
<roptat>I suppose I could use something like this to push scala, gradle, and other stuff ;)
<drakonis>^
<drakonis>that's a use case
<drakonis>they're fsdg standards compliant but not guix standards compliant
<roptat>the scala package I sent to guix-devel didn't get a lot of support, but there are users who would like to still use it
<dstolfa>nckx: something like strongswan would belong in contrib given the state it was/is in right now. it's not fully integrated with guix, so it would need to start there
<dstolfa>it's a part of upstreaming process, if you will
<dstolfa>a "debian testing" in a way, but for guix
<drakonis>hell, even some experimental functionality
<ixmpp>an NUR-like architecture sounds like a very good idea
<ixmpp>then the burden of maintenance is on the namespace, not the entire repo
<drakonis>the staging grounds for something like guix home before it makes into guix mainline
<dstolfa>however, it isn't quite the same thing as debian testing, as here the "testing" would refer to new services, new complicated bootstraps, etc
<yoctocell>ixmpp: +1
<dstolfa>it wouldn't refer to new packages
<ixmpp>so as long as your stuff doesn't break building the channel, it can get merged
<ixmpp>that way, stuff is infinitely more accessible
<ixmpp>infinitely more visible
<ixmpp>and very tidy
<nckx>Imagine I don't know what ‘Debian testing’ or ‘contrib’ (pointless abbrev) mean.
<nckx>Because I don't 😛
<roptat>I think the idea is that guix has the fsdg and a certain quality assurance policy that raises the bar very high for some difficult packages
<roptat>contrib would be a place where the QA bar would be lower (but fsdg still enforced since it would be officially part of Guix)
<dstolfa>nckx: so, this would be a repository that would contain packages and services that aren't yet fully fleshed out. they aren't tested with a wide number of configurations, have some problems in a guix environment (e.g. only partial functionality and potential bugs), but are still useful to some users. the "contrib" repository would host those, things that are work in progress, but require a significant amount
<nckx>dstolfa: Wouldn't this better be handled outside of Guix? Basically next-door, since there will an overlap in contributors, but why does this have to be a Guix Project?
<dstolfa>of effort to actually get working in a guix environment.
<nckx>OK, I'm lagging again, sorry all.
<dstolfa>nckx: quite simply: assurance of FSDG and being able to trust a central entity (guix) rather than a random repository online
<roptat>I think it's not a discussion we should have here, but rather on the ML where we can elaborate more on the idea?
<dstolfa>(trusting an umbrella/project vs trusting an idividual)
<dstolfa>individual*
<dstolfa>roptat: yeah, that might be true
<drakonis>how long does the initial email have to be in the first place?
<roptat>because then you'll have to explain everytime someone arrives :)
<ixmpp>reasons for guix to move to xmpp ;)
<roptat>however long you need to explain the idea, and maybe give one or two examples
<nckx>I appreciate everyone writing so much here and it's clear there's a need to be addressed, but I also think this is more suited to mail than IRC. Don't ask me why.
<dstolfa>i guess it started on irc to get a feeling on whether or not it's worth even discussing
<nckx>So the NUR is reviewed by Nix people?
<roptat>and maybe a contrib channel is not the right solution, so it'd be nice to try and explain the problem it's trying to address, maybe we can think of something else
<drakonis>nckx: nope
<nckx>dstolfa: Sure, that's what IRC is very very good at.
<drakonis>its a bunch of repos coalesced together into a umbrella repo with a script
<drakonis>its... serviceable but not elegant
<drakonis>there's no guarantees that it follows any rules or that things work together
<nckx>‘I like cats’ ‘Huh me too’ ‘OMG I had no idea so many people like cats’ → Mail to make cats head of Guix.
<drakonis>someone could sneak up some bad code and there wouldnt be any overhead until caught
<dstolfa>(and just to be clear, i don't need any of this, i'd just be in favor of it and be happy to help set it up where ever possible for someone who's an outsider)
<ixmpp>the onus of maintenance of a subdirectory of the NUR is specifically and unilaterally on it's owner. the users of NUR code accept that the code has nowhere near the reliability guarantees of Nixpkgs. NUR stuff tends to eventually wind up in Nixpkgs, because people use and want it, see it, and work collaboratively to upstream it
<drakonis>that's exactly what i'd like to avoid
<drakonis>the main issue with NUR is that unless you're highly invested in the community, you're not going to find it
<drakonis>besides what i wrote previously
<ixmpp>well i figure since the issue people here seem to think will hold it back is the maintenance
<ixmpp>remove that from the equation
<ixmpp>but realistically, maintenance of a contrib repo = ensuring any merge keeps the channel buildable
<ixmpp>nothing more is required
<ixmpp>it's not upstream guix
<nckx>But we already have channels.
<nckx>This already exists.
<ixmpp>the problem is visibility
<dstolfa>(and the fact that non-free software easily sneaks in there)
<ixmpp>compounded by the fact that every channel uses a different git host
<drakonis>there is a risk that we havent talked about
<nckx>Yes, you're asking to advertise some channel (in the installer, maybe, or elsewhere) but then make zero guarantees or commitment to anything, depending on who you ask above.
<nckx>This is what I need loving help understanding.
<drakonis>about whether it encourages people to push to contrib instead of aiming for mainline
<ixmpp>e.g. me looking for discord on nixos, i just search github (heh). me looking for it on guix? i google and hope for the best. maybe there's a channel on some tiny gitlab somewhere, unlikely it's indexed though
<ixmpp>so sure, i can post systemd on my channel in cgit on my webserver, but who's gonna find it
<dstolfa>nckx: i think the guarantees of the repo would be simple: "this is free software, but isn't quite ready for mass consumption and full integration with guix. feel free to test for your usecase, but don't expect it to work fully yet"
<nckx>ixmpp: Why can't you search GitHub for it?
<ixmpp>in my case, you can
<ixmpp>but i only know of three guix channels on discord
<ixmpp>every other one is on a random other host
<nckx>dstolfa: So it's expected to be audited by the Guix project.
<ixmpp>s/discord/github/
<nckx>‘Kept an eye on’, at least.
<nckx>But an attentive one.
<dstolfa>nckx: yes, as these are things that would ideally go into guix at some point, but take a lot of effort to do so in 1 patch/patch series
<nckx>Right.
<dstolfa>think complicated languages, things like systemd suite, etc
<ixmpp>the guarantees as i see it are literally just that it builds as part of the channel, and that it's free software
<ixmpp>anything more is only necessary as part of audit for upstreaming to guix proper
<nckx>This sounds like a ‘try it now!’ (‘testing’, if you will 😉) addition to the patch tracker.
<nckx>That makes more sense to me than the {N,A,X,…}UR metaphor.
<dstolfa>yeah, it's basically to allow people to test software that we'd want, but isn't fully ready yet (and is FSDG-compliant!)
<ixmpp>sure, just as with nixos almost everyone has a crazy hack to merge in unfinished PRs from nixpkgs, because that's where all the actually useful stuff is
<ixmpp>but fiddling with patches, and merging in dirty PRs are both unweildy solutions
<ixmpp>and as i did say earlier, if the result is months of arbitration and gathering dust, i'm very unlikely to be incentivised to submit patches in the first place, whereas if i can put them in a contrib repo with low barrier to entry, that for sure i will always endeavour to do
<ixmpp>that's a comment on me, and other potential committers, not on the project
<dstolfa>the trade-off would be patch review over time rather than having to review a giant patch series all at once for inclusion, anad because it's over time and available to users really easily test and report bugs for, it will hopefully have better quality in the end
<rekado_>it’s not right for me to jump into this discussion, so I’ll just leave a link to some comments here: https://logs.guix.gnu.org/guix-hpc/2021-06-09.log#220148
<nckx>Someone can just create this today, look for like-minded contributors (a few already here), show how awesome it is, then ask to promote it in Guix? Rather than describing it and waiting for someone™/the project™ to make it happen. The work is in the doing.
<nckx>If *that* sounds like too much work for uncertain gain, we can be almost certain the thing would have died anyway.
<ixmpp>i believed the plan was to just split nonguix into nonguix-nonfree and nonguix-contrib anyway, not sure how we ended up discussing it again
<dstolfa>rekado_: that's fair, i think i'm thinking of a slightly different "contrib" which should probably just be named "work in progress", as all of this should have a goal on getting in guix
<nckx>Calling it ‘WIP’ is so much clearer.
<nckx>‘contrib’ is dumping an ugly baby on someone's doorstep and expecting them to be thankful & raise it.
<dstolfa>LOL
<drakonis>lmao, that may be a little too correct for my tastes
<drakonis>too accurate
<nckx>I think that's my way of sharing rekado_'s linked concerns.
<dstolfa>yeah, i think WIP is probably a better name for what i have in mind at least
<dstolfa>i think all of this should be on the path to getting in actual guix
<dstolfa>not just a bunch of code people dump in a repo
<nckx>‘WIP’ says as much as downloading a random patch on the ML. It makes it *easier* which is good. But it's still clear you can't safely assume it will work or keep working unless you help push it forward.
<dstolfa>agreed, and maybe there should be some policy on moving things out of WIP once the effort stops
*nckx believes that all babies deserve love and that even the old-man-facedest babby can grow into a beautiful (strong)swan; it's merely the doorstep bit I object to.
<rekado_>I don’t like other people’s babies.
<dstolfa>so i guess the first step for this is to actually move it to the mailing list and get people's takes on it, perhaps discuss what happens if people stop pushing code to a WIP part, how much maintenance it would be, would it make sense to do now or maybe revisit at some point later due to constrained resources right now, etc?
<nckx>Good because I was specifically worried about offending you.
<nckx>dstolfa: Sounds good.
<ixmpp>for sure. my problem is situations e.g. like when i was trying to upstream my guix module to nixpkgs. it built, it was functional, and plenty of people had approved it, but the clouds hadn't aligned so it hadn't been merged even after a literal year of my screaming down the irc and github. as a person, i get overwhelmed very easily, and that was an extremely unpleasant experience for something i was trying to
<ixmpp>do as a favour to other people (i.e. upstreaming my work rather than keeping it to myself). all i want is that initial barrier to entry to be lowered so i don't end up overwhelmed, my intention is not to ditch babies everywhere, but my predisposition is also not typically to upstream things anyway
<nckx>dstolfa: Also a big fan of having something existing to point to rather than something cool to describe.
<dstolfa>nckx: yeah, a PoC is always good
<nckx>I don't mean ‘it's like X’, but ‘we made Y’. Right.
<civodul>ixmpp: re systemd, i replied in the issue tracker, let's keep the discussion there
<ixmpp>fwiw as a result of that situation i resolved to just never contribute to nixpkgs again, and kept my word :D
<ixmpp>civodul; oh, sure, it's just the only example i have rn
<civodul>i explained the tradeoffs, which are specific to this package
<ixmpp>i don't often use mailing lists. always feel like i'm gonna forget to reply-all someday
<nckx>Yes yes it's no XMPP‌ :o)
<nckx>Most clients can be configured to handle it somewhat cleverly. Most.
***niko is now known as o
<ixmpp>heh
***sneek_ is now known as sneek