IRC channel logs


back to list of logs

<ieure>Are there patches out there for newer glib and gtk4? I've seen that some folks are working on GNOME things, and suspect these are likely to be part of that.
<casaca>hello o/ i have a patch to emacs-xyz. i made it aginst the master branch, should it be made against the emacs-team branch? ty
<isaneran>is there a way to check in a guix scheme file what the current guix command is? (other than extracting it from (command-line) )
<isaneran>would like to have a file that when I run guix system vm on it it returns just the operating system and if i run guix deploy on it it returns the list with machine etc
<adanska>Hi Guix!
<parnikkapore>Hi Guix! What's the policy for dealing with software that uses ?
<peanuts>"GitHub - camgunz/cmp: An implementation of the MessagePack serialization format in C /[C]"
<parnikkapore>cmp recommends that projects copy the files straight to the build tree, and even Debian doesn't have a separate package for it; do we de-vendor this or leave it in the dependent package's tree?
<lilyp>I mean, we do try to unvendor gnulib in places, so…
<parnikkapore>lilyp: yeah that'd be one point in favor of devendoring
<parnikkapore>although gnulib at least has a debian package
<gabber>peanuts: come back here, buddy!
<civodul>Hello Guix!
<bumble>if anyone would move this pyqt6 patch along it would give me a joyful holiday season
<efraim>I have to say, building the kernel and guix itself for riscv64 is probably the slowest part of creating a new image
<efraim>FOSDEM proposal for the distro room submitted!
<gabber>hacking on a service i try to create i run into "error: serializer: unbound variable" -- do in need to import something else than (gnu services configuration) for that?
<parnikkapore>Hi Guix! What's the policy for dealing with software that uses ?
<parnikkapore>cmp recommends that projects copy the files straight to the build tree, and even Debian doesn't have a separate package for it; do we de-vendor this or leave it in the dependent package's tree?
<civodul>parnikkapore: hi! i’d say it’s a bit clearer if we unbundle it, because then we see which version of cmp packages depend on
<civodul>but then again, if that’s too inconvenient in practice, and if even Debian gave up ;-), we can reconsider
<parnikkapore>actually doing it isn't that difficult (it'd be an extra build phase that copies the files over), the issue is next to no one else is doing it
<parnikkapore>so I guess it's worth a try!
<parnikkapore>anw, let's say that there's a project developed on github that uploads release source tarballs to both sourceforge and github, how should the source be fetched? git-fetch the repo, url-fetch from GH, or url-fetch from SF? Let's say that the source tarball and git repo have the same contents
<parnikkapore>(this is for lsp-plugins in case you're wondering)
<civodul>make sure the package definition doesn’t refer to generated tarballs (‘guix lint’ warns about it, at least for
<civodul>then i’d recommend ‘git-fetch’ if the source tarballs don’t have anything additional
<civodul>the only case where tarballs make a difference AFAIK is when using the Autotools: they contain generated build machinery that the repo typically doesn’t have
<parnikkapore>yeah, the github tarballs are user-uploaded ones, not the generated ones
<parnikkapore>so git-fetch is preferred in cases like this?
<parnikkapore>thanks anyway :)
<gabber>how can i get from a (text-file) to a /gnu/store path from within a #~(make-forkexec-constructor) in a shepherd service? is it even possible?
<civodul>gabber: hi! see ‘plain-file’
<civodul>you can try it at the REPL: ,lower (plain-file "foo.txt" "Hello!")
<mrvdb>efraim: did you see my note on the zink problem? upgrade of mpv was sufficient. Might be worth applying? see also
<efraim>mrvdb: I read it but glossed over the part where you upgraded mpv to 0.37
<efraim>mrvdb: want to send a couple of patches to upgrade it?
<gabber>civodul: thanks for the hint!
<gabber>any hint on where to put #~ and #$ respectively in there ?
<mrvdb>efraim: sure, though i need to read up on what you guys expect, not normaly running from guix source tree (assuming that is needed)
<civodul>gabber: ah in this case you would use ‘mixed-text-file’ rather than ‘plain-file’
<civodul>‘mixed-text-file’ allows you to insert references to packages etc.
<civodul>whereas ‘plain-file’ expects a plain string for the file contents
<gabber>and where do i need to put the #$ (if anywhere)? i now run into an unreadable gexp-input-error
<gabber>from the error message it's really hard to tell if this is now better or worse:
<civodul>gabber: #~(code …) means that (code …) is staged for later execution
<civodul>here, ‘match-record’ shouldn’t be staged; it should be executed as soon as ‘resize-fs-script’ is called
<civodul>thus: (define (resize-fs-script config) (match-record config … (mixed-text-file "" …)))
<civodul>there’ll be no #~ and no #$ in this case :-)
<gabber>makes sense
<gabber>the error is now less unreadable (but it's still a gexp-input-error) :(
<gabber>i am trying to ,lower that expression in a guix repl with the default configuration
<civodul>note that ,lower expects a “file-like object” (package, plain-file, mixed-text-file, etc.), not a gexp
<gabber>but my (resize-fs-script config) does return a mixed-text-file, no?
<gabber>ah, does file-append return a gexp?
<civodul>yes, it returns a mixed-text-file
<efraim>do you need to resize it on the device or is it an SD card that you can resize before inserting it?
<civodul>no, file-append also returns a “file-like”
<gabber>efraim: i could resize it before inserting it
<GuixNoobOleg>Greets! I've installed Guix today in a virtual machine, from the iso file (rather than the ready VM image). Im having trouble getting spice-vdagent going, to get resolution changes + host-guest clipboard. I would have expected that this is done by a (service ...), but that gives me a error on guix system regenerate about this being deprecated. A
<GuixNoobOleg>simple guix install spice-vdagent doesn't give me a service start, nor does it give me the spice-vdagentd daemon. Any pointers on where to go? I assume this is a trivial one or two lines in config.scm, but this is my first attempt at Guix so I'm not sure what the right approach is
<vivien>GuixNoobOleg, in (gnu services spice), you have a spice-vdagent-service-type
<vivien>(I don’t know about the deprecation)
<GuixNoobOleg>Hm, I tried it again and it seems that my reconfigure is going nicely without warnings
<GuixNoobOleg>Well that was fun, the service works fine now with no warnings. I tried yesterday, and got the deprecation warning.
<GuixNoobOleg>I reinstalled the VM today, obviously I've done something better this time '=D
<GuixNoobOleg>Thanks for the confirmation that I was on the right track originally. The spice-vdagent-service-type works exactly as it should
<jeremyc>How can I view the news of my previous guix pull? I forgot to do guix pull -N, now I'd like to see that news.
<ryblade>i did a duh. i typed "sudo guix pull". i know. how do i undo this and return things to the way they were before i used sudo without coffee?
<civodul>ryblade: ctrl-c :-)
<ryblade>civodul: lol, the deed is already done :(
<futurile>Afternoon Guixers
<ryblade>morning, futurile
<ryblade>it's all relative
<civodul>ryblade: ‘guix pull --roll-back’ then!
<ryblade>at least it's not october 9th 2061 like an old machine of mine said it was earlier today, think i need to buy another CR2032
<ryblade>civodul: just to be sure, what privileges should i be using when i do that? should i do that as my normal user, with sudo, or as root proper (like at a console)?
<civodul>ryblade: you can run ‘guix pull’ as a normal user, that’s the “normal” way to use it
<ryblade>yeah, i know that, i'm just wondering how to correctly get rid of the guix binary that's now in /root/.config/guix/current
<ryblade>unless i should just leave that alone
<ryblade>usually i make sure to not use sudo when invoking guix pull, this morning... bad brain day, what can i say.
<ryblade>it's okay, i figured it out. ran it as root, it switched to generation 0, nothing under 'guix pull -l' now.
<efraim>what error is 139?
<civodul>efraim: tip: (status:term-sig 139) => 11 (aka. SIGSEGV)
<civodul>IOW, that’s not good
<efraim>during the test phase for guix on powerpc-linux, inside tests/git.scm
<efraim>[1377561.883077] guile[15594]: segfault (11) at 10139000 nip fed8380 lr fed8340 code 1 in[feb0000+cb000]
<efraim>I'll add guile-git to the list of packages that I should debug on powerpc-linux
<vivien>lilyp, how do I close an issue when it has already been applied? I have a list of mine
<vivien>The list is: #66813 #67164 #67318 #67409 #67415 #67421 #67422 #67465 #67467 #67468 #67471 #67472 by the way
<vivien>These are all my issues for which all patches have been applied already
<vivien>I’ll try things :)
<vivien>(I should now receive 20 messages from debbugs)
<vivien>(How To DDOS Yourself)
<vivien>It doesn’t seem to work
<vivien>I closed the first, and then debbugs sent a confirmation. With renewed confidence that what I was doing worked, I then sent an email to all of the
<vivien>(all of the remaining ones)
<vivien>My server signed the email and delivered it to all of them
<vivien>I haven’t had any response from debbugs yet
<vivien>Are there protections on debbugs to avoid closing multiple issues at once?
<Guest43>If a software itself is GPL-3 but it is a launcher for a proprietary video game, it is not compatible for upstream?
<vivien>OK I have to do 1 at a time
<ieure>Guest43, Not sure, maybe guix-devel would be a good place to ask.
<vivien>Yay I closed *everything*
<mirai_>Guest43: as long it doesn't include the nonfree bits in question, it's fair game
<Guest43>mirai: that is very nice
<lilyp>vivien: message to or message to with the close command
<vivien>lilyp, I did the first option
<jackhill>hmmm, QA doesn't seem to like for some reason
<vivien>jackhill, same for I have no idea why
<attila_lendvai>if my system doesn't boot because it dies in a shepherd start GEXP, and i get a guile debugger prompt... is there a way to start a bash? or any other way to boot in "safe mode"?
<efraim>attila_lendvai: I'd suggest rolling back and testing your service with a vm
<attila_lendvai>efraim, rolling back doesn't work because it's due to a change on the fs i have made. i'll boot some live disk and undo it
<attila_lendvai>ACTION managed to fix it with a live usb, and will continue working on hardening shepherd
<cmiller>I am using default Guix in a VM with GNOME as DE and added spice-vdagent. The VM uses latest revision of Guix. My system is ~ 70 days old. I have a huge offset with the mouse. Is this because the VM is newer than my host?
<cmiller>also GDM auto login is not working. I did remove the vdagentd service and now GDM auto login works and there is no issue at all.
<cmiller>Even if the version was bumped, shouldn't they be compatible?
<mwette>Does paperclip4465 (from github) hang out here? I'm looking for insight into how he got a gcc cross compiler to build with newlib. (There is a chicken-egg issue with building gcc and newlib).
<cmiller>If I run "guix home reconfigure" after running "guix gc", it needs to fetch everything again. Why?
<ieure>cmiller, Because the GC deleted them. Maybe gc doesn't know about the home profile and thinks those weren't needed?
<cmiller>ieure: Yeah but isn't that the wrong behaviour? If store items are required for a profile, they should not be deleted.
<attila_lendvai>ieure, that would mean that guix gc would break things unless you run a home reconfigure right after it -- which is not the case in my experience
<cmiller>yep, can confirm. They are still present in the store but they shouldn't be fetched again
<vivien>gnome-team, this issue is for you! #67651
<vivien>Note how I did not add you in CC as you would then reply to
<cmiller>after texlive, the transaction of guix home reconfigure breaks. This is a 100% chance for me. Sure, I can just try again but it should not happen in the first place.
<lilyp>I'll have a look at it later. Some subquestions have a simple answer, others not so much.
<cmiller>(I meant after guix home reconfigure fetches the texlive package, which is 3GiB in size and defined in my guix home packages list)
<attila_lendvai>cmiller, if you have guix pull'ed inbetween the two home reconfigure (regardless of gc), then the texlive package may have changed due to an input package, even without its version changing (different hash => needs download)
<cmiller>attila_lendvai: I did not pull. That is my I think this behaviour is wrong. It does not make any sense.
<attila_lendvai>cmiller, i don't fully understand grafting, but that may also influence this
<iK0u>Has anyone managed to use this? Is it expected to work atm?
<iK0u>Was not even able to build the image last time, unfortunately