IRC channel logs

2021-03-09.log

back to list of logs

<pkill9>is there a way to take existing packages from profiles and move them out into new profiles, such that they aren't rebuilt but are 'recycled' from the old profile?
<lispmacs[work]>hi, I'm working on configuration that old 32 bit laptop I mentioned previously. I've got a configuration set up for lxqt + slim + connman + cmst: https://bpa.st/LFWQ
<lispmacs[work]>however, when I try to run cmst to see my network configuration, I get dbus errors: https://bpa.st/KGDQ
<lispmacs[work]>does anybody have any insights for me?
<lispmacs[work]>I see now that it has to be run as root.
<lispmacs[work]>does connman have its own special permissions group or something?
<lispmacs[work]>my user is a member of netdev
<ryanprior>pkill9: when you remove a profile the packages aren't removed until you do "guix gc". So if you remove the packages from one profile and add them to another, nothing should be rebuilt.
<pkill9>ryanprior: this is using a profile with packages built with different revisions of guix
<pkill9>i'm just building/downloading them all again instead
<pkill9>but it would be helpful
<ReilySiegel>Hello! I am new to Guix, and am having a difficult time understanding/finding documentation on the preferred way to set up user-level services (such as syncthing). Are all services meant to be defined in the operating-system level?
<atw>hi ReilySiegel, I took the advice in https://guix.gnu.org/en/blog/2020/gnu-shepherd-user-services/, and syncthing is one of the examples given. Could that help?
***scs is now known as Guest81063
<ReilySiegel>Im having a few issues with this approach. Firstly, it appears that a user level shepherd service is not started automatically on login, which results in the same problem. Furthermore, using the init.scm provided causes an error that seems to cause shepherd to immediately exit when run manually: WARNING: Use of `load' in declarative module (#{ g54}#). Add #:declarative? #f to your define-module invocation.
<ReilySiegel>I have attemted to add the required define-module statement, but as I dont fully understand the guix module system, that resulted in further errors.
<mange>ReilySiegel: Are you on a Guix system, or a foreign distribution? I'm on a foreign distribution and I get systemd to start a user shepherd service on login, but when I was on a Guix system I started shepherd as a part of my desktop session (with xfce).
<ReilySiegel>I am on guix system, so I will work out a way to get the shepherd process started. However, I am still having an issue with shepherd immediatly exiting after starting. Even if I place the syncthing service directly in the init.scm file, it appears that the shepherd process immediatly quits, and is unaccessable via the herd command.
*pkill9 is containerising all the things
<ReilySiegel>Upon further inspection, it seems that the issue is caused by the line (action 'shepherd 'daemonize). If this line is removed, the shepherd starts as expected, but does not daemonize. Is this a known issue?
<c4droid>Hi, someone use xmonad in guix system? I wrote a simplest xmonad config, when recompile, report cannot find ghc. I saw the system profile, it use ghc@8.6.5, else for install the latest ghc and run ghc-pkg recache, have any solution can solve?
<apteryx>ReilySiegel: perhaps you just got surprised but the utter silence of the daemonized shepherd?
<apteryx>I thought it didn't work too, at first
<pkill9>why doesn't SSL_CERT_DIR get set when running `guix environment --ad-hoc curl` even though it's a search path in curl's packae deifnition.
<apteryx>I think the files the search path points to need to exist in the profile
<apteryx>i.e., you need to also include nss-certs
<pkill9>ah yea
<pkill9>thanks
<apteryx>np
<ReilySiegel>apeteryx: I am unable to access the daemonized shepherd using the herd command, and the socket no longer exists. Furthermore, the issue persists even when starting shepherd undaemonized and later daemonizing it with herd daemonize root. As soon as the shepherd is daemonized, it becomes unavailable to the herd command.
<ReilySiegel>This isnt a huge issue, I should be able to start shepherd in .xprofile using "shepherd &" instead of using the build-in daemonization feature, but it would be nice to figure out the "proper" way to do things.
<apteryx>I have a configure using 'daemonize that works here; let me share it
<apteryx>the services definitions were hastily put together without much effort; be warned! https://paste.debian.net/1188467/
<pkill9>this is working so nicely, you can install addon packages with just the programs which use them, and they will find them thanks to search paths
<ReilySiegel>I am encountering the same problem with your config (I disabled the part that starts the services). I guess I will jsut stick "shepherd &" in my .xprofile somewhere
<apteryx>perhaps a .go cache problem
<apteryx>try a 'find -name '*.go' -exec rm {} +' where you keep your shepherd services definitions
<daviid>apteryx: would you mind a quick look in #guile, I posted a quiz for you, that should only take a sec to answer ... tx!
<ReilySiegel>apteryx: Unfortunately that does not solve the problem. The output of the shepherd command (using the config for syncthing) is Service root has been started.
<ReilySiegel>Service syncthing has been started.
<ReilySiegel>Exiting shepherd...
<ReilySiegel>Service syncthing has been stopped.
<apteryx>daviid: :-) thanks for the ping
<apteryx>ReilySiegel: I'm not sure what the problem might be then :-(
<c4droid>I just follow the guix blog setuped herd user services, only cannot automatically start when login the normal user accounts. :)
<ReilySiegel>apteryx: This might sound really dumb, but after a restart, the problem fixed itself. I have no idea what caused it, but its working now.
<apteryx>ah! I've had this kind of moment before; happy that it worked; unhappy I couldn't understand the root cause of the problem ;-)
<pkill9>which fonts does icecat need?
<pkill9>found it
<apteryx>dejavu-sans mostly, but it should already be configured as a default fall-back for fontconfig, IIRC.
<apteryx>well, to be clear, I don't think it needs thes fonts specifically; they just happen to work well
<c4droid>Has anyone ever encountered an `xmonad --recompile` error where can't find ghc in system profile?
<pkill9>i install gnu freefont, cos it was mentioned on a bug issue
<apteryx>c4droid: did you install ghc explicitly to your system profile? (i.e., added to the 'packages' field of your operating-system record) ?
<apteryx>I don't use xmonad, but perhaps it expects it to be installed along (e.g., not propagating it itself)
<c4droid>apteryx: I was install the ghc in system profile, but the ghc-xmonad-contrib's ghc input is ghc@8.6.5, not ghc@8.8.3
<c4droid>I installed ghc@8.6.5 can pass the compile
***iyzsong-- is now known as iyzsong-w
<apteryx>ah! It'd be useful to try to update xmonad to use the same ghc version as our current ghc
<apteryx>I'm sure many users will trip otherwise
<c4droid>apteryx: And have method can start shepherd when login the normal user accounts?
<c4droid>like login hooks or custom scheme proc
***scs is now known as Guest13375
<apteryx>there's nothing at the operating-system level yet to handle per-user services
<apteryx>there's a project called guix-home-manager that caters to this (and more)
<apteryx>as a side note
<raghavgururajan>leoprikler: Did I come close? https://paste.debian.net/1188472/
<raghavgururajan>I now get "In procedure copy-file: Permission denied".
***samis is now known as CompanionCube
***drakonis- is now known as drakonis
<jackhill>join #loko
<jackhill>oops, sorry!
***jx97 is now known as jx96
<ReilySiegel>Hello, im having an issue setting up hibernation on my Guix System laptop. It looks like saving the image to swap works fine, but upon booting, the system is unable to find the swap partion (resume= is set, and the kernel shows the correct UUID when booting). Is there additional configuration for Hibernation that I am missing?
<lle-bout>hello! :-D
***scs is now known as Guest28582
<Rovanion>Does anyone have a comment on this patch? https://issues.guix.gnu.org/46805 I think the long car-cdr line is ugly, could it be improved?
<jackhill>Rovanion: indeed, we usually try to avoid car and cdr in Guix. I haven't thought too much about the data your working with there, but the general recommendation is to do pattern matching from (ice-9 match).
<leoprikler>raghavgururajan: I responded to your mail, is the paste still relevant?
<raghavgururajan>leoprikler: I could still prettify using the last paste.
<leoprikler>Rovanion: This might be a good fit for match-let*
<leoprikler>Indeed, that is an idea.
<leoprikler>If it helps you match the shared objects, go for the for-each install.
<raghavgururajan>leoprikler: I would add shared-objects to the list. But I would like to first make it work with headers.
<raghavgururajan>leoprikler: https://paste.debian.net/1188472/
<raghavgururajan>I now get "In procedure copy-file: Permission denied".
<h_art9ine>Hello, I happen to be new and young so please take me slow. I have just installed guix on Fedora and am not sure how to cross build Hurd on it, or may I say use Hurd and not linux. I want to be part of a totally Free Ecosystem.
<h_art9ine>Also looking for a mentor; Want to build native state of the art software for the Hurd.
***scs is now known as Guest91961
<leoprikler>raghavgururajan: what's the full error?
<leoprikler>h_art9ine: I don't think Hurd is quite ready for the metal yet. Guix System has some capabilities for setting up Hurd VMs, but I'm not sure how to use them on a foreign distro.
<raghavgururajan>leoprikler, https://paste.debian.net/1188481/
<leoprikler>Hmm, it looks like some headers might already be present?
<Rovanion>Thanks jackhill and leoprikler, I'll have a look at match and match-let*.
<leoprikler>yep, qtsingleapplication vendors qtlockedfile
<leoprikler>you might want to patch that earlier on
<raghavgururajan>oh wait
<raghavgururajan>I missed the sub-dir
<leoprikler>you mean the directory excursion?
<raghavgururajan>(string--append "include/" solution)
<raghavgururajan>*(string-append "include/" solution)
<leoprikler>oh, right
<raghavgururajan>No i get Wrong type to apply: "\\.h$"
<raghavgururajan>May be '(...)
<leoprikler>uhm, stupid questions, but wouldn't it still make more sense to put it into a shared include dir?
<leoprikler>and unvendor lockedfile?
<raghavgururajan>my brain hurts
<raghavgururajan>I am again going in circles.
<raghavgururajan>I mean with the errors.
<leoprikler>trust me, you really don't want to quasiquote in the install plan
<h_art9ine>pls. help here: GUIX_PROFILE="$HOME/.guix-profile"
<h_art9ine> . "$GUIX_PROFILE/etc/profile"
<h_art9ine>sorry here: guix install: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory
<leoprikler>uhm, how exactly did you set up your guix?
<leoprikler>I think your guix-daemon might not be running
<h_art9ine>guix installation script: wget https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
<leoprikler>fedora uses systemd right?
<Rovanion>leoprikler: Yes.
<raghavgururajan>leoprikler: The make cleans the shared libs.
<raghavgururajan>before install phase
<leoprikler>wdym?
<raghavgururajan>leoprikler: The generated .so files get removed from the build-dir.
<raghavgururajan>That;s why I used the PWD hack.
<mothacehe>cbaines: Hey! I saw you enabled rust build on aarch64/armhf, with f5c6e69. Does it work for you? Looks like the build farm cannot build rust on aarch64 (see https://ci.guix.gnu.org/eval/145882).
<leoprikler>raghavgururajan: it should be moved to $PWD/lib, which should be the same as (string-append solution "/lib")
<cbaines>mothacehe, hi!
<cbaines>I have to admit I didn't check before pushing, but looking at this build and where it failed https://ci.guix.gnu.org/build/374228/details
<cbaines>that's this derivation I think https://data.guix-patches.cbaines.net/gnu/store/f3aqa38fnx9fcf70jywb32lav5dgk224-rust-1.21.0.drv
<cbaines>and it seems to have been successfully built once at least
<cbaines>hmm, however, rust-1.26.1 doesn't seem to have built successfully yet https://data.guix-patches.cbaines.net/gnu/store/c3f7d3ziwjfkwg3j7xz47dj44sb2l5av-rust-1.26.2.drv
<mothacehe>cbaines: oh, interesting. I think we should still disable it for those archs until it builds consistently though.
<cbaines>mothacehe, I think that's OK for now, although the failures are a little less visible when the derivations aren't computed
<cbaines>I guess since the rust bootstrap gets stuck at rust-1.26 on aarch64-linux, that can be removed from the supported systems list at that point?
<raghavgururajan>leoprikler: You mean
<raghavgururajan> ("lib" "lib"
<raghavgururajan> #:include-regexp ("\\.so$"))
<mothacehe>cbaines: yup, guess so. To be honest, the main issue is that all the workers are trying to build rust-1.26 and are stuck doing so (https://ci.guix.gnu.org/workers). Once build dependencies support is implemented in Cuirass that problem will be mitigated.
<cbaines>mothacehe, yeah, I'll push a change to the supported systems shortly
<mothacehe>thanks :)
<leoprikler>raghavgururajan: yep
<cbaines>looking at the logs, the failures occur in the 'check phase, so I wonder if things would get further for aarch64-linux if the tests weren't run
<cbaines>I think that's the case now on core-updates for rust, but I haven't checked
<raghavgururajan>leoprikler: For some reason I get No such file or directory
<mothacehe>we could maybe open a bug entry to keep track of that failure
<cbaines>yeah, I'll open one now so I can reference it in a comment
<raghavgururajan>leoprikler, https://paste.debian.net/1188486/
<leoprikler>I think you ought to `guix build -K`
<raghavgururajan>leoprikler: Oh never mind. The error is during run-path validation, not during install. https://paste.debian.net/1188487/
<mothacehe>great!
*raghavgururajan throws in some flags
<civodul>mothacehe: hey! not sure if you saw my message re wip-build-systems-gexp yesterday; could we add it to ci.guix?
<mothacehe>civodul: hey! yeah I did it yesterday :)
<mothacehe>it already built some stuff!
<cbaines>mothacehe, I've pushed https://git.savannah.gnu.org/cgit/guix.git/commit/?id=a72888995173ace3190c69d324265dcc5fd66d3e now, although I guess the damage is already done, this change will just prevent new builds from being added, right?
<efraim>hello everyone!
<Whyvn>what is the recommended way of install something with pip since /gnu/store is note writeable
<efraim>Whyvn: with the --user flag, although making a guix package is preferable
<mothacehe>cbaines: right, but I'll cancel those builds manually, thanks for your support!
<mothacehe>hey efraim!
<Whyvn>efraim: thanks, im still trying to get my head around making packages.
<cbaines>civodul, regarding wip-build-systems-gexp, the Guix Data Service claims to have processed it, but I think some of the error handling broke. Looking at the log, there was a weird derivation-missing-output-error from the inferior https://data.guix-patches.cbaines.net/job/11567#bottom
<cbaines>civodul, I don't know if that's something from the changes on that branch or not
<efraim>I got guile-3.0.5 to build on powerpc-linux. Just rebased wip-ppc on core-updates locally, if I can build to hello I'll push the updated branch
<efraim>I also need to see about letting guile upstream know
<civodul>mothacehe: great, thanks! :-)
<civodul>mothacehe: BTW, could you update cuirass-howto.org in maintenance.git?
<mothacehe>civodul: I'm almost done rewriting Cuirass evaluation, so this howto will become mostly obsolete.
<mothacehe>but I'm improving Cuirass documentation accordingly and I'll write a new howto.
<civodul>that's even better :-)
<civodul>having a cheat sheet for SQL hacks might still be useful tho
<mothacehe>yup
<civodul>cbaines: looks like a genuine issue: &derivation-missing-output-error derivation: #<derivation /gnu/store/dm8a673yq3xdxgqia011xpajq2bvc135-kconfigwidgets-5.70.0.drv => 7f39b82ae5a0> output: "out">>
<raghavgururajan>Phew with QtSolutions
***scs is now known as Guest53508
<raghavgururajan>leoprikler: For leading with \t, you mean like this?
<raghavgururajan> (("\t\\.\\./3rdparty/qtlockedfile/?.*")
<raghavgururajan> "")
<leoprikler>no i really mean [ \t]*
<leoprikler>meaning just eat all whitespace
<raghavgururajan>(("[ \t]*\\.\\./3rdparty/qtlockedfile/?.*")
<efraim>0 or more spaces or tabs
<leoprikler>exactly
<civodul>cbaines: qt-build-system was creating zero-output zero-input derivations :-)
<civodul>should be better now
<cbaines>civodul, great :)
<cbaines>civodul, I also noticed errors in the form: warning: importing module (...) from the host in that log
<cbaines>s/errors/warnings
<cbaines>I haven't seen them before, so I guess they relate to the changes on that branch too?
<ss2>hi! Is there a way to read all the `guix pull --news` from the past?
<leoprikler>I think `guix pull -l` would do that.
<ss2>Think I have to reword my question again. :)
<leoprikler>oh you mean all the news since the inception of Guix?
<ss2>I know that every now and then there are news to be read in a pull, but are they collected somewhere, so that I can read through them?
<ss2>kind of.
<leoprikler>Ahh, yes, there's a news file per channel.
<leoprikler>For Guix, that's etc/news.scm if I haven't mistyped it
<ss2>yes, thank you. Just hadn't found that file yet.
<ss2>neat that it is published in other languages too.
<leoprikler>no, it's always Scheme :)
<leoprikler>we don't publish in C or JSON.
*nckx joins, notices awkward silence, leaves.
<nckx>Morning Guix.
<raghavgururajan>nckx o/
<raghavgururajan>leoprikler: Out 4 instances of leading spaces, [ \t]* works on 4th one. For any of 1st, 2nd or 3rd, I get `Parse error. Function missing ending ")". End of file reached.` during configure phase.
<raghavgururajan>*out of 4 instances
<leoprikler>do you also swallow the brackets at the end? perhaps we're overly eager in matching file names
<leoprikler>(never forget to `guix build -K`
<leoprikler>)
<raghavgururajan>Looks like only 1st. The other 3 works.
<raghavgururajan>leoprikler: https://paste.debian.net/1188498/
<raghavgururajan>for that line, there no brackets on either side
<raghavgururajan>*there are no
<leoprikler>why does it break with [ \t]* then?
<xelxebar>What provides libgcc_s.so.1?
<nckx>raghavgururajan: "stuff.*" matches the trailing newline "\n", so you're substituting two "somestuff\nmorethings" lines into one "somemorethings" line, which is probably not what you want. There are some other strange decisions (why "/?.*", since the "/?" is implied by ".*" anyway?) but they don't look breaking.
<nckx>xelxebar: gcc ☺
<nckx>gcc:lib, to be precise.
<raghavgururajan>holy shit
<nckx>raghavgururajan: Try solving your immediate problem with "\n" as replacement, not "", that might just work.
<raghavgururajan>does ?.* go beyond line?
<raghavgururajan>*one line?
<leoprikler>the .* part does
<nckx>Well, no, but it includes the newline, so that's philosophical.
<nckx>raghavgururajan: ☝
<leoprikler>you might want to end it in \\.(cpp|h)$
<raghavgururajan>What if I do ?.*$
<nckx>Forget the ?, it's not relevant, it belongs to /.
<leoprikler>or skip the $ even
<raghavgururajan>> leoprikler‎: you might want to end it in \\.(cpp|h)$
<raghavgururajan>I endedup doing that
<leoprikler>for the ?, you might want to do (|.*)
<xelxebar>nckx: Hrm, that's what I saw in the forums, but `guix environment --ad-hoc gcc:lib` errors out that "gcc-toolchain lacks output lib"
<xelxebar>Not sure how to actually access the gcc package
<nckx>xelxebar: That's because gcc != gcc-toolchain; gcc-toolchain is supposed to be the user-facing alternative for the hidden gcc package.
<nckx>gcc-toolchain is for installing with ‘guix install’ etc, gcc is the actual GCC package used to build Guix packages. So we need to know exactly what you're trying to do to (try to) (too many tos) help.
<xelxebar>nckx: Trying to build an environment capable of running a pre-built binary.
<xelxebar>So just going through the output of ldd path/to/binary and trying to install the missing libs in an environment.
<nckx>It's possible that no ‘guix install’able package provides that library (intentionally -- maybe some do by accident).
<nckx>For example you used to be able to install gfortran to work around it, but that loophole has since been closed.
<xelxebar>Hrm. What's the rationale for barring users from installing that lib?
<nckx>If you already use a custom channel, or Guix System, you can quite easily define a custom gcc package that unsets hidden-package.
<nckx>xelxebar: It wasn't about the library, it's about people running ‘guix install gcc’ without reading the docs and complaining that ‘GCC is broken on Guix’. So GCC was hidden in favour of gcc-toolchain, which provides a working toolchain, but nothing more, so now we get GCC bug reports anyway 😛
<nckx>Hiding it is a mistake but I don't have a better solution to the original problem.
<xelxebar>Haha! Damned if you do damned if you don't. I see. Thanks for the hint about the custom channel workaround. I was unaware that packages could be hidden.
<xelxebar>Maybe renaming the gcc package makes sense? gcc-you-probably-actually-want-gcc-toolchain, perhaps?
<nckx>You can probably just add (properties '()) to your variant without breaking anything; the field isn't used for much else.
<nckx>xelxebar: That GCC is used to build all of Guix, and the NAME field determines the store directory, so at the very least you'd rebuild the entire distro to link every programme against libgcc_s.so.1 => /gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-you-probably-actually-want-gcc-toolchain-7.5.0-lib/lib/libgcc_s.so.1 (0x00007aa700d30000)
<nckx>It's not a stupid suggestion, but it's fixing the problem (if there is one?) in the wrong place, again.
*nckx → lunchies.
<nckx>(Oh: I don't actually know if missing /lib is a deliberate feature of gcc-toolchain; maybe that can just be fixed? Worth asking.)
<xelxebar>Ouch. That would be painful. I see. So the core problem is that we have gcc and gcc-toolchain packages which are different enough that they can't just be variants on gcc, right?
<raghavgururajan>leoprikler: Sent v16. :-)
<xelxebar>nckx: Here's another dumb idea that avoids rebuilding. Expose the gcc package via an import wrapper named something like gcc-non-toolchain. Would this cause issues?
<xelxebar>Still a hack though :P
<raghavgururajan>nckx: Would you be able to apply updates from #47016 and #47017?
<i1l>sneek: botsnack
<sneek>:)
***scs is now known as Guest33678
<abcdw>good afternoon guix!
<efraim>do we need a debug output for gcc-cross-boot0?
<efraim>oh wow, the debug output is 75% of the size of the output
***^_ is now known as V
<PurpleSym>How can I get a list of all currently failing packages (for a given architecture/branch) from the Data Service or CI?
<efraim>guix weather --display-missing will get you part-way, but not quite what you're asking for
<raghavgururajan>leoprikler: What do you mean by unvendoring?
<leoprikler>Vendoring is the act of including a dependency as source code. Unvendoring is the act of undoing that vendoring.
<leoprikler>Particularly for qtsolutions the qtlockedfile is vendored in qtsingleapplication.
<raghavgururajan>leoprikler: So you want me to patch the qtsingleapplication to use qtlockedfile from $ROOT/qtlockedfile/src?
<leoprikler>patch the build system thusly and remove the vendored sources, yes.
***vup2 is now known as vup
<cbaines>PurpleSym, sounds like you're looking for this page https://data.guix-patches.cbaines.net/revision/a72888995173ace3190c69d324265dcc5fd66d3e/package-derivations?search_query=&system=x86_64-linux&target=none&minimum_builds=&maximum_builds=&build_status=failing&field=system&field=target&field=builds&after_name=&limit_results=&all_results=on
<cbaines>so, on the package derivations page for a revision, you can filter by build status
<leoprikler>Is there a way of expressing a "null" derivation in Guix, i.e. a derivation, that does exactly nothing?
<PurpleSym>cbaines: Ah, yes, that’s what I’ve been looking for! Thanks!
<PurpleSym>cbaines: When is the build status “failing”? If all substitute servers fail to build it or just one?
<raghavgururajan>leoprikler: Looks like QtLockedFile inside QtSingleApplication is different from the other QtLockedFile.
<leoprikler>lemme diff real quick
<cbaines>PurpleSym, it's not about substitutes, just if there is one failed build that exists, and no successful builds. Note that the build information is just a couple of build farms that I operate mostly
<leoprikler>just a namespace it seems
<leoprikler>you know how to deal with namespaces
***scs is now known as Guest28120
<efraim>cbaines: thanks! I just fixed compiling xygrib
*pkill9 is going to containerise even sway itself
<raghavgururajan>yep! thanks.
<pkill9>fnstudio: actually what i am doing is similar ot qubesos I think, except for individual applications
<pkill9>i think I will even be able to containerise sway itself
<rekado_>pkill9: do you plan on writing a blog post and/or cookbook entry for this? I would love to read about it.
<pkill9>I can run sway in a container, and if I can make a daemon that lets containerised applications open containerised applications, then hopefully I can have containerised sway show containerised applications - which aren't a subcontainer of the sway instance, meaning they have access to files the sway instance doesn't (namely their own files), while unable to access sway's files or any other application's files, yet still show it's window in the
<pkill9>containerised sway instance
<pkill9>from a couple tests I've done this seems it can be done
<pkill9>rekado_: yes i will, even just for my own sanity
<pkill9>I'm trying to make this as simple and clear as possible, so it can be relied on
<pkill9>I kind of have a mental diagram of what it looks like
<nckx>pkill9: I would also subscribe to your newsletter.
<pkill9>this is kind of like an interactive workflow language, with contained statefulness
<pkill9>or something
<pkill9>combined with guix's ability to run applications without 'installing' them (although the flexibility of guix makes the term installation kind of irrelevant), it will be pretty nice
<raghavgururajan>leoprikler: Looks good? https://paste.debian.net/1188533/
<leoprikler>qtlockedfile?. <- nani?
<raghavgururajan>hmm?
<raghavgururajan>different CASE
<leoprikler>[eE]
<raghavgururajan>actually QtLockedFile is harmless and is a dummy file.
<leoprikler>also unvendoring should always be done in snippet
<raghavgururajan>Ah
<nckx>raghavgururajan: ‘nani’ is weeb for ‘what’.
<nckx>Talking mainly to myself because TIL.
<raghavgururajan>to delete files with _unix and _win suffixes.
<leoprikler>but why the question mark?
<raghavgururajan>tiredness?
<raghavgururajan>I;ll remove it.
<raghavgururajan>leoprikler: Good? https://paste.debian.net/1188537/
<leoprikler>the corresponding substitute* needs to be moved as well
<leoprikler>substitute*s, plural
<raghavgururajan>That;s patching source
<leoprikler>Who says you can't patch source in a snippet?
<raghavgururajan>I didn't say I can't. Is it necessary to patch source in snippet?
<raghavgururajan>we usually remove 3rdparty/bundled/vendored files in snippet. which is done here.
<leoprikler>We also usually patch away build system and source references to those bundled/vendored/3rdparty files in the snippet, which is not done here.
<raghavgururajan>we didn't do this with telegram.
<raghavgururajan>But okay. I;ll do it.
<leoprikler>If we didn't do this with telegram, that's my oversight.
<raghavgururajan>Cool! No worries!
<raghavgururajan>I'll do it.
<raghavgururajan>leoprikler: Good? https://paste.debian.net/1188541/
<nckx>raghavgururajan: The rationale is that ‘guix build foo --source’ should return something that actually builds. In practice we fall short of that more often than not, but it's worth trying.
<raghavgururajan>nckx: You builds the package or just the source?
<Ikosit>Hi guix! Is somebody here using pipewire as replacement for pulseaudio?
<raghavgururajan>Ohh so it's like ‘guix build foo --source’ giving cleaned source, correct?
<leoprikler>i.e. you do `tar xvf $(guix build -S pkg); guix environment pkg` and can start hacking on package.
<raghavgururajan>I see.
<nckx>raghavgururajan: Ideally, yes.
<raghavgururajan>Gotcha!
<i1l>Ikosit: https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/doc/overview.md
<i1l>> For consumer audio, we use PulseAudio
<i1l>> For Pro audio, we use JACK
<leoprikler>That may be written there, but that's not at all what it means.
<i1l>NObody expects the spanish pulseaudio. *tune*
<i1l>cool, "we" isn't "we". just a line more and i weren't mistaken so badly (just had read that today).
<Ikosit>Let me rephrase my question: Is somebody using the pipewire-daemon instead of the one from pulseaudio?
<raghavgururajan>nckx, leoprikler: Does lambda work inside snippet?
<raghavgururajan> https://paste.debian.net/1188543/
<raghavgururajan>doesn't apply the substitute
<leoprikler>because lambda creates an anonymous function
<raghavgururajan>what?
<leoprikler>inputs → %build-inputs and your good
<raghavgururajan>*what's that
<leoprikler>an anonymous function is a function without a name
<raghavgururajan>That was my first instinct, but got unbound variable.
<raghavgururajan>for %build-inputs
<leoprikler>hmm, you can replace it with @input@ and then substitute that with (assoc-ref inputs "input")
<raghavgururajan>you lost me.
<raghavgururajan>(assoc-ref @inputs@ "kwidgetsaddons")
<raghavgururajan>?
<leoprikler>no
<leoprikler>instead of (assoc-ref inputs "kwidgetsaddons") inside snippet you write "@kwidgetaddons@"
<raghavgururajan>ah
<leoprikler>actually, you can do that for the full string-append
<leoprikler>then you replace that with what it should actually be
<raghavgururajan>"@kwidgetsaddons@/include/KF5/KWidgetsAddons/"?
<pkill9>i'd like to know if anyone uses pipewire too Ikosit
<civodul>looks like an xvfb-run commit broke things?
<raghavgururajan>leoprikler: Works. Thanks!
<i1l>didn't seen the input with many origins before: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/telegram.scm#n404 . wonder if that always been possible.
<civodul>nckx: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=07f77812c44aa3b7a6b963613b783da56110d2f0 is invalid
<i1l>i1l: ah, that actually wrong. same indent.
<nckx>For a scary moment I thought you meant the signature.
<raghavgururajan>i1l: You brought back some memories. xD
<civodul>nckx: fixed; could you make sure to install etc/git/pre-push? :-)
<civodul>it runs "make", which can be annoying at times, but avoids that
*pkill9 wants a pinephone running guix system
<nckx>You can't be serious. I just ran git fetch && git push and you already managed to push during the &&. Make takes several minutes here.
<nckx>Yeah, I noticed 😒
<raghavgururajan>leoprikler: My bad! You didn't over-look anything with Telegram. :-)
***[df]_ is now known as [df]
<leoprikler>I'd like to feel proud now, but I'm not going to check.
***scs is now known as Guest72330
*raghavgururajan feels the slience in #guix
<katco>> * <@freenode_pkill9:matrix.org> wants a pinephone running guix system
<katco>yes. i wish i had more time to work on all the things i'd like.
<samplet>Hm.... I have a Disarchive package, but I don’t know where to put it.
<samplet>Right now it’s in a new “metadata.scm”, but that seems too vague.
<samplet>Maybe “archival.scm” is better.
<nckx>Supernoob question: is this Pinephone something I could actually rely on as my first and primary (well, only) mobile telephone? Rough edges are fine, missing edges are not.
<samplet>I could shoehorn it into “package-management.scm”.
<nckx>samplet: 's What I was going to suggest.
<nckx>archival.
<nckx>samplet: Really? My horn would break if I tried that.
<samplet>nckx: Thanks! It doesn’t matter that much, but I’m easily defeated by choices. :)
<nckx>Go with your gut. As long as it agrees with mine, of course, that is.
<samplet>Two guts in the hand are better than one in the bush!
*nckx grins madly.
<nckx>samplet: Just to throw you back into agony: there's also backup.scm.
<nckx>HMMM.
<samplet>I think I’ll stick with “archival”. It kinda goes along with the Software Heritage /Archive/, which would be strange if it were the Software Heritage Backup.
<samplet>Maybe the added layer of managing the information instead of just duplicating it makes the difference. Of course, it’s all pretty fuzzy.
*samplet is justifying an arbitrary decision
<nckx>Yeah. FWIW I agree, but it made me ponder the nature of things whilst machine rebooted.
*nckx wonders what ‘scheduled Software Heritage archival’ actually implies because they're guix linted some weird stuff.
<nckx>Not proprietary, just crap.
<nckx>Please-don't-save-this-for-the-ages type stuff.
<nckx>So I hope there is an added layer of human management with a strong stomach.
<samplet>nckx: If it’s on a known host (e.g., Gitlab), it’s automatically accepted. If it is blocklisted, it is automatically rejected. Otherwise, it goes to a manual check.
<samplet> https://docs.softwareheritage.org/devel/apidoc/swh.web.api.views.origin_save.html#swh.web.api.views.origin_save.api_save_origin
<nckx>Thanks.
<nckx>I'm... hm. That's an... bothering a human is an odd thing to do when I run a local lint check.
<nckx>I don't like doing that.
<nckx>Time to read the code.
<efraim>nckx: I've had one for almost a month, still haven't put a SIM card in. I've heard mms doesn't work yet and can block sms until cleared in the terminal.
<efraim>It's a bit slow, but I don't think enough so to rule it out based on that alone
<nckx>Is the latter the reason (something mms something sms) for not putting the SIM card in?
<nckx>Hmkay. I was wondering how future-proof it was; ‘it's already a bit slow’ answers that. Thanks.
<efraim>I don't make a lot of calls and mostly use unnamed proprietary messaging apps. I have a hard enough time trying to stick to just fdroid
<nckx>Damn it I just want a computerphone‌ ☹
<nckx>Why does an entire factor suddenly have to suck and opress by design, I don't really understand.
<efraim>I really want it to work
<nckx>*form factor
<nckx>The baseband thing I get, stuff like Android I don't.
<efraim>I even managed to use firefoxos for almost a year back in 2015, I actually liked it
*efraim goes afk
<nckx>It was off-topic anyway, although I explicitly wanted the opinion of #guix, not #pinephone.
<civodul>no GSoC for GNU (and thus Guix) this year :-/
<emacsen>civodul, aww
<civodul>looks like they're saving money
<civodul>hey samplet! Disarchive package, woohoo! :-)
<samplet>civodul: Yeah! I still feel funny about it, but I agree with you that the way forward is to start using it.
<samplet>Should I send patches or just commit?
<samplet>(It’s just disarchive and guile-quickcheck.)
<bavier[m]>is there something like `guix size` that works on manifests?
<dustyweb>civodul: yeah I just saw that email
<dustyweb>surprising
<dustyweb>it looks like they've also done some other changes to the program
<dustyweb>in that students were only being given half the hours they were given other years
<dustyweb>my guess is that the program got its funding cut but I don't know
<efraim>civodul: the test-out-of-memory test fails on powerpc-linux too on 3.0.5
***scs is now known as Guest10881
<avalenn>I see a lot people uses scissors lines on the mailing-list.
<avalenn>Is this an enforced convention ? or due to the use of a tool where it is default ?
<dustyweb>civodul: btw not sure if you saw
<dustyweb>but gsoc also has halved the hours this year
<dustyweb>> For 2021 we are excited to offer smaller sized projects and thus a lower time commitment for those interested in participating in the program. In 2021 all student projects will be 175 hour projects (instead of the previous 350 hr projects) and the coding period will be 10 weeks.
<dustyweb>hence me thinking it's probably a funding thing. but who knows.
<dongcarl>Question: on Debian, I know that /proc/sys/kernel/unprivileged_userns_clone needs to be set to 1 for Guix to work. I'm a bit confused about why this is the case, especially when guix-daemon _is_ running as root? Or is this only necessary when using `guix environment`, which setups namespaces as the current user?
<ngz>Hello
<apteryx>sorry, I've forgotten once more; what exactly do I need to do to have icons available in a pure environment?
<apteryx>I thought it had to do with XDG_DATA_DIRS being set (such done via glib), but that doesn't seem to be enough
<efraim>I assume they halved the money too
<dustyweb>efraim: yep
<cbaines>dongcarl, I'd guess that you're correct. The guix-daemon is probably fine, it's just guix environment --container and guix system container as non root users that require user namespaces
<cbaines>(unprivileged user namespaces)
<dongcarl>cbaines: Cool, thanks!
***leoprikler_ is now known as leoprikler
<Artemix>hhm, I was wondering about something, for system usage of guix. How do you deal with configurations targeting VMs or systems where the part uuid is regularly changed?
<Artemix>(the case for VMs is "every time I set up a new VM with this guix system config, I have different uuids")
<Artemix>like, is there a way to point to specific device partitions, e.g. /dev/sda2
<lfam>Artemix: Right, you use device names or filesystem labels. Labels are probably more robust
<Artemix>labels would be the best way to go, indeed. And can easily be automated for server vm bootstrapping. I missed the man part about filesystem handling in guix, and found out about it the moment you pinged me
<lfam>Serendipity!
<leoprikler>raghavgururajan: why are we not building the qtsolutions examples? (just so I know)
<Artemix>yup. Still have lots of trouble navigating in the docs, but I have like a total of 4 hours playing with both guile (not my first scheme, thankfully) and guix. I'll get there at some point
<efraim>can I wrap all of #:phases in an if statement?
<leoprikler>if you do your quoting correctly, yes
<leoprikler>what that results in may however not be what you want
<Artemix>hm, btw, I haven't been able to find anything in the main pkg channel, but is a distribution of the qemu-guest-agent packaged ?
<efraim>I'm touching binutils but only want to affect powerpc-linux. I'm checking with ./pre-inst-env guix build -d hello --system=i686-linux. I figure if it doesn't change it should work
<efraim>I think I got it right, still might need to touch binutils-final in the end
<lfam>Artemix: I think it's part of the QEMU package
<lfam>There's a `qemu-ga` executable provided by it
<Artemix>huh, I thought that the qemu package would've pulled the whole hypervisor so I didn't bother checking its internals and settings
<efraim>alright! fixed it so now I'm straight back to binutils-final
<lle-bout>Artemix: there's no service for the guest agent though, it needs to be made
<ss2>hm. I'm trying to add blueman to to dbus-service list. But it is failing.
<ss2>I always get this error after login: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.blueman.Mechanism was not provided by any .service files (2), and reading as per the manual, I should add blueman to the dbus-service list.
***scs is now known as Guest28001
<Artemix>lle-bout, thanks for the info. I guess it'll be a good way to learn about services.
<lle-bout>Artemix: guest agent is only necessary to transfer files for example, the rest is already handled by the Linux kernel as-is
<lle-bout>Artemix: Or handled by the spice-vdagent service that exists in GNU Guix
<Artemix>hhm... proxmox noob; the guest agent is used on proxmox to pull stats such as ip. would spice-vdagent be able to handle that / compatible (open question, I'm about to document myself on that)
<mhj[m]>Hi all, I keep getting errors when reconfiguring the system. Like, it says that it's a network error according to the auto backtrace, but these errors used to never occur like they do now...
<mhj[m]>But can't be the network because I'm using a wired network connection, so it's just weird.
<mhj[m]>Or it can be, I guess... I dunno.
<lle-bout>Artemix: yes that also, no spice-vdagent wont, spice-vdagent more so is for desktop usage of VMs
<mhj[m]>Mind if someone takes a look at the trace on debian paste?
<lfam>Did you share the link mhj[m]?
<mhj[m]>Hold on
<mhj[m]> https://paste.debian.net/1188588
<mhj[m]>Do I need post more, if need be I can post the whole thing.. hopefully lol
<cbaines>mhj[m], do you get the same error if you try again?
<mhj[m]>I'll try again!
<lfam>Can you search the bug reports? I think this has been reported recently
<lfam>I recognize the weird corruption in the error messages
<cbaines>it could be this issue you're thinking of lfam https://issues.guix.gnu.org/46967
<mhj[m]>It seems to be working now... weird
<lfam>Yes cbaines
<mhj[m]>BTW, I don't have any experience with dealing with bug reports, but I'll how if it'll benefit the Guix team!
<lfam>If you wanted to participate in that bug ticket, you could send a message to <46967@debbugs.gnu.org>. Or you could use the web interface that cbaines linked to
<mhj[m]>Ahhhh
<mhj[m]>I'll bookmark the web interface!
<ss2>okay, got it working, but that didn't get rid of this message.
<frhcf>has anyone been able to install emacs-native-comp from the flatwhatson repo on guix on a foreign distro (Ubuntu 20.04)? For some reason after `guix pull` I can't see the emacs-native-comp package.
<frhcf>I've put more detail here: https://github.com/flatwhatson/guix-channel/issues/2
<mhj[m]>Let me see if I can reboot into the new system btw
<lfam>frhcf: You should use `guix describe` to see if you are using the channel
<mhj[m]>Because after running "guix system reconfigure my-system.scm" it went through completely.
<mhj[m]>Er, running it again
<lfam>frhcf: Oh, also: "/home/mark/.guix-profile/bin/guix"
<lfam>That's incorrect. Did you install the Guix package with Guix? Like, `guix install guix`? You shouldn't do that
<mhj[m]>And thanks for all your help lfam and cbaines . I'm still learning the ins and outs of the system.
<lfam>We are happy to help, mhj[m]
<lfam>frhcf: Feel free to keep asking questions
<frhcf>lfam, guix describe only shows this:
<frhcf>```
<frhcf>guix describe
<frhcf>  guix a53f711
<frhcf>    repository URL: https://git.savannah.gnu.org/git/guix.git
<frhcf>    branch: master
<frhcf>    commit: a53f711422f63d7e32b8639b968cf00bcc69ffea
<frhcf>```
<lfam>Right, so that means you aren't using the channel. The other thing I pointed out shows that your Guix installation is misconfigured
<frhcf>Yeah, sounds like a good candidate.
<lfam>You should check if you've mistakenly installed Guix with itself using `guix package --list-installed`
<lfam>If you have, then do `guix remove guix`
<lfam>The value of `which guix` should always be '~/.config/guix/current/bin/guix'
<frhcf>OK, looks like that might have been the problem...
<frhcf>I do have another guix which I installed with guix. I don't remember doing that, so I couldn't tell you why I did it!
<lfam>I actually don't use any channels so someone else will have to help with those details, if necessary
<lfam>It's okay, many of us have done it at some point or another
<lfam>We'd like to make it less likely, somehow, but it belies some UX / UI bugs that seasoned Guix users are blind to
<frhcf>It's a bit of an odd thing to be able to do.
<frhcf>But I'm sure there is a reason.
<lfam>To give a little more detail, by default, Guix uses two "profiles". There is the profile of packages you choose to install, and that profile is found at ~/.guix-profile
<lfam>But, Guix handles itself in another profile, and that's the one found at ~/.config/guix/current
<frhcf>Ah, I see. That is definitely worth knowing.
<lfam>You can inspect with the normal package management tools by specifying this non-default profile, e.g. `guix package --profile ~/.config/guix/current --list-generations`
<lfam>I mean, it exists by default, but it's not the default for the `guix package` command
<frhcf>Ah, I see. That is worth knowing.
<lfam>I agree, it's odd that it is possible to do. We need to fix this eventually
<frhcf>And I guess that's the one that gets updated on a `guix pull`, when there are new versions of the guix command?
<lfam>Exactly
<lfam>There is also `guix pull --list-generations`, which does something similar.
<frhcf>very neat. thanks for that, one piece at the time it'll all start to make sense.
<lfam>It actually does more than the `guix package` version, but it can be a little slow, since it computes things
<lfam>So, I use the `guix package` version for quick inspection... and switching :) One of the great features of Guix
<lfam>I always missed `apt-get update --rollback` on Debian. Now, it's trivial :)
<frhcf>It seems like a really great piece of technology. I can see myself coming to like it a lot once I'm used to the basics.
<frhcf>It almost begs the question "why haven't we been doing it this way all along"
<lfam>Heh, good question
<lfam>I think there are several factors that made it possible / likely to happen when it did
<lfam>For one thing, this model uses more disk space than old-school distros. But storage is super cheap and fast now
<lfam>Cryptographic hashing is also super fast now
<lfam>And that led to Git being invented, which I think inspired a lot of related technology
<frhcf>Yeah, it seems very git-inspired.
<lfam>30 years ago, it cryptographic hashes were not available or way too slow
<lfam>That's my understanding anyways. I was a toddler 30 years ago
<frhcf>I wasn't aware of the increase in hashing speed. That's interesting. That does explain a lot of recent trends in tech that relies on hashing.
<frhcf>I always assumed it was purely disk space related.
<lfam>I also think that, as disks got bigger and processors got faster, we made bigger systems, and they got too big to understand without better tools, etc
<lfam>It's like a feedback loop of resource consumption and complexity
<lfam>There wasn't even a solid understanding of cryptography outside of the military that long ago
<lfam>I think we are only at the beginning of this field of knowledge
<pkill9>can SElinux work with guix? Since i think SElinux relies on access controls to individual files, but on guix these files are constantly changing
<frhcf>Yeah, I'd love to understand that field a bit more. I have a decent understanding of git, but when it comes to hashing and cryptography it's a dark art to me.
<frhcf>Thanks for the help lfam. Really appreciated. I was banging my head against the wall for quite a while on that one. :)
<lfam>I know what that can be like. Don't hesitate to ask for advice
*lfam afk
<frhcf>very kind of you.
<frhcf>right, let's see if I can give the emacs native comp branch a whirl....! This should be fun.
<apteryx>when is the static output of gcc-toolchain needed?
<apteryx>it doesn't seem to be needed to *build* static archives; so I'm wondering what's its purpose.
***fr33domlover1 is now known as fr33domlover
<mhj[m]>Yay, my raspberry pi pico came in. I know, off-topic lol
<mhj[m]>Altho I would love to see Guix on ARM devices, and eventually the hurd on ARM devices too lol
<apteryx>ah, I think gcc-toolchain:static may be needed to create C++ static programs
<apteryx>mhj[m]: enjoy :-)
<mhj[m]>Thanks apteryx! I’ve experimented with stuff like the microbit and the Adafruit trinket or feather, something like that, but I’ve heard the documentation for this is amazing. And you can run Unix on it, a Unix called Fuzix. It’s cool. Someone is porting emulators to it lol
<efraim1>sneek: botsnack
<sneek>:)
<jeko>Hi Guix !
<efraim1>hello!
<jeko>efraim: hey !! Just yesterday I used with your tips from Online Guix Days 2020 !
<jeko>to create my second ever package definition haha
<jeko>and play with it locally
<jeko>so handy
<jeko>efraim1: oops with the right nick it's better haha
<efraim1>I'm on both ATM, I'm trying out an IRC client written using EFL libraries
<jeko>what's its name ?
<efraim1>express, but there's a name collision with another package already in guix
<jeko>ouch
<efraim1> https://git.sr.ht/~efraim/my-guix/tree/master/item/dfsg/main/express.scm
<lle-bout>imagemagick 6.x in GNU Guix has unpatched CVEs, however upstream only releases fixes for 7.x, identifying security-related commits and backporting is very troublesome work, can we just upgrade to 7.x in GNU Guix? I see a comment saying 7.x has incompatible API, yes but people can always use an inferior but we can't become an imagemagick security team to backport each and every patch, upstream has to do that if they want to, if they
<lle-bout>don't we can only upgrade to newer versions and break compat unfortunately..
<efraim1>looks like imagemagick@7 isn't packaged yet
<lle-bout>efraim1: yes
<efraim1>wouldn't be a bad idea to package it and see if it can work as a drop-in replacement
<lle-bout>efraim1: look at comments in imagemagick package, it has incompatible API
<lle-bout>From quick glande, commit history indicates several security issues fixed without CVEs issued
<lle-bout>glance *
<lle-bout>So the only way to make sure we are up to date w.r.t. security patches here is to use the latest version always
<lle-bout>efraim1: okay nevermind apparently there's a different repo for version 6, rather than branch: https://github.com/ImageMagick/ImageMagick6
<lle-bout>So imagemagick upstream does maintain 6 still, all good
***scs is now known as Guest23264
<efraim1>we are several versions out of date though
<lle-bout>efraim1: I am making the upgrade
<efraim1>it's going to have to be a graft, too many dependants
<lle-bout>efraim1: we will need to graft I am afraid
<lle-bout>yes
<apteryx>dongcarl: was there an issue related to the troubles you had with GCC ?
<dongcarl>apteryx: Not really, you just gotta make sure it's in your LIBRARY_PATH
<lle-bout>efraim: I also see a security-related commit without a release: https://github.com/ImageMagick/ImageMagick6/commit/2a56e447a4a60a4b89fc8be0410a6db39d5e3de3 - so we will have to repeat this soon as well.
<apteryx>dongcarl: I think I might be hitting it but I'm not sure it's the same thing, could you share the kind of errors you were getting, and how you could workaround it? The issue tracker is a fine place for it, I tihnk.
<dongcarl>My most recent problems were with the "lib" output rather than the "static" output :-.
<dongcarl>:-/
<apteryx>the problem I face doesn't seem to have to do with static either
<apteryx>I'm trying to build static libraries, and they complain about not finding C++ standard stuff at link time
<dongcarl>Not sure the exact problem but I would try: 1. Look at which library it's complaining about... libstdc++? 2. Make sure that libstdc++.a (or whatever the standard archive is) is in your LIBRARY_PATH or at least in `gcc -v -E -xc++ - < /dev/null > /dev/null`
<apteryx>such as: upnp_context.cpp:(.text+0xa4be): undefined reference to `std::__cxx11::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::basic_ostringstream()'
<apteryx>here's the full output: https://paste.debian.net/1188608/
<apteryx>I think it may have to do with mixing Guix libraries with building static archives; I got a good build earlier where more of Jami's daemon libraries were bundled, but I'm now hitting this after trying to use more system libraries.
<apteryx>I don't quite grok what the issue is yet
<apteryx>it could be that I must include all of the static outputs of the dependencies used; I'm not sure if GCC is able to create .a from source files + shared libraries
<leoprikler>Reading the MLs right now, can someone explain "vogue[0] not a joke" to me?
<nckx>I don't get it either.
<lle-bout>unrelated: don't know if anyone noticed how 'guix search gtk+' results are bad because of the '+'
<nckx>lle-bout: How bad?
<jackhill>Fortunately, I think GTK has officially dropped the +, not that that will help as long as people keep searching for gtk+
<lle-bout>nckx: gtk+ is probably 10+ position in the list
<lle-bout>while it matches the search query *exactly*
<lle-bout>searching 'gtk' or 'gtk+' actually gives same results for GNU Guix
<nckx>Yes.
<nckx>OK, you're right lle-bout, I was just expecting worse.
<nckx>Wildly irrelevant stuff! Chaos!
<nckx>lle-bout: Any idea why
<nckx>*?
<lle-bout>nckx: probably special handling of +? Not sure there
<leoprikler>Some licensing stuff for the evening, what does "license: 'LGPL-2.1+ and GPL-2.0+'" mean?
<jackhill>hmmm, gtk without the + doesn't seem to do much better, does it?
<nckx>I can reproduce it only when I don't escape the +.
<lle-bout>jackhill: that's also because the + is in the package name
<nckx>That's not a bug, is it?
<lle-bout>nckx: I didnt know 'guix search' had macros with '+'? Does it?
<nckx>I don't understand the question.
<lle-bout>Maybe we can disable those since I don't see a use case for '+' search macros right now?
<nckx>What's a search macro?
<lle-bout>special handling of character..?
<nckx>But how is ‘+’ handled specially?
<jackhill>lle-bout: oh interesting
<nckx>Are you not escaping it?
<lle-bout>nckx: why would I need to escape it?
<nckx>Because ‘gtk+’ matches ‘gtk’ exactly.
<lle-bout>nckx: but why would + need to be escaped?
<lle-bout>why is it a special character in the first place?
<leoprikler>guix search gtk\\+
<nckx>But it's not.
<nckx>Yeah.
<leoprikler>perhaps we do regex?
<nckx>guix search --help
<nckx>leoprikler: We always have.
<leoprikler>yeah, that's why then
<kcurtet>Hi guys someone know how to have a node env for version 14 or 15
<nckx>So what's the bug?
<nckx>lle-bout: Could you give an example of what you expect to happen vs. what does?
<leoprikler>well the "bug" is that some might expect raw string match :)
<lle-bout>I expect raw string
<kcurtet>I tryied python-nodeenv but it says file not exists when i run the executable
<leoprikler>"+" is special because we do regexp by default
<nckx>Usage: guix search [OPTION] REGEXPS...
<nckx>Search for packages matching REGEXPS.
<nckx>
<lle-bout>I think regex should definitely be an option but other package managers e.g. apt also check for exact match *before* processing regex
<nckx>We could add a ‘--fixed-strings’ option similar to grep.
<kcurtet>Why i can't run downloaded executables in distros like guix and nix?
<nckx>kcurtet: Because they rely on fixed files like /lib/ld-linux-x86-64.so.2 that Guix and Nix lack by default.
<nckx>And need help finding other libraries too, since they're not all in one(ish) well-known location like /usr/lib, but each in their own directory.
<kcurtet>nckx: thanks. any workaround?
<lle-bout>I think adding such option might increase UX complexity for not much benefit, we could either agree on not using regex special characters in GNU Guix package names or automatically check exact match *before* regex, don't know