<ruffni>i need to update ancient python print calls to print() statements. i'm struggling with substitute*. if i match like this: (("( +)print (.+)" _ ws arg) (format #nil "~aprint(~a)" ws arg)) the closing paren lands on the next line (newline seems to be part of arg).
<zzappie>There probably should be a flag for that? not sure
<BlackMug>ok guix install icedove and tell me what will happen
<raghavgururajan>nckx: If tests fail due to missing schema that is provided by the package itself, I'd move 'check after 'install and also (setenv "XDG_DATA_DIRS" (string-append (getenv "XDG_DATA_DIRS") ":" (assoc-ref outputs "out") "/share")).
<BlackMug>i see, yeah well im user facing vms type
<Aurora_v_kosmose>I've been pushing stuff into VMs anyway for isolation but the friction it engenders by using the setup for purposes it isn't quite suited for is what has me consider biting the bullet and moving to Qubes.
<BlackMug>been like 7 years with VMs with vbox,kvm,xen due to whonix contribution
<vagrantc>i do think it would be valuable to keep guix's deblobbing machinery available ...
<vagrantc>a local caching proxy sort of thing ... otherwise, even with shallow git checkouts, each time guix downloads a git origin, it typically redownloads a lot of things that it probably wouldn't have to
<vagrantc>though something as simple as a daemon that does on-demand git checks and then performs the requested pull/fetch/etc operations if it doens;t already have what was requested
<vagrantc>much like the url-fetch has a mirror:// method, i think, which falls back to other servers
<apteryx>sneek: later tell vagrantc I recently let mhw know about that decision, so they wouldn't be surprised when the change hits the patch tracker; they told me while they still disagree with it, it's a rather small thing in the bigger picture and they are ready to let it go.
<tissevert>sneek: later tell roptat I haven't been able to log into Fedora's translation thing: it won't accept the password I saved and the password-reset procedure crashes too (I've received a HTTP 500 error each time I tried during the weekend). I'll try again later
<fnstudio>rekado: i think it looks alright on my machine
<fnstudio>there doesn't seem to be any extra new lines
<vivien_>If guix supported XML_CATALOG_FILES, I could store a copy of the texlive source in my hard drive and guix would not have to download it from the web ^^
<vivien_>Guile has a fcntl function that does not lock or unlock files and a flock function that locks files. In C, we have fcntl and flock that behave differently. Which one does guile use for its flock function?
<vivien_>OK I’ve found it in posix.c, it’s C flock
<sneek>roptat, tissevert says: I haven't been able to log into Fedora's translation thing: it won't accept the password I saved and the password-reset procedure crashes too (I've received a HTTP 500 error each time I tried during the weekend). I'll try again later
<Rovanion>Sure, I'm just copy-pasting wildly in a "happy when it works on to the next package" kind of way.
<rekado>texlive-generic-babel-swedish looks fine, though
<rekado>could you send me a patch for that package or tell me how you’d like to be credited?
<Rovanion>If its okay with you: Rovanion Luckey <email@example.com>
<roptat>apteryx, we probably want to squash the doc patches before pushing them to master
<rekado>Rovanion: actually… we can do better there as well :) I’ll update the package to use the “new” style and I’ll give you a co-authored-by credit.
<roptat>when trying to guix pull (as root and as user), I get guix pull: error: Erreur Git : failed to resolve path '/root/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq': Aucun fichier ou dossier de ce type
<Rovanion>Haha, I'm happy either way. Thank you for your help rekado!
<rekado>a lot of the packages in gnu/packages/tex.scm are still old-style, predating the use of simple-texlive-package, etc
<roptat>I can work around that by removing my ~/.cache, but that's not great, why does that happen?
<roptat>I wonder if it should be the same patch though
<roptat>at least for master, I think there would be one patch that replaces the pot-update target with the pot target directly (and that removes the po-update targets), and a second patch that is the one I sent yesterday, wdyt?
<apteryx>hmm, that could be neat; on the other hand an observer would have to go through "ah! these commits were reorganized before merge, okay"
<apteryx>actually, I'm not sure I correctly understood what you had on mind, especially that bit of your reply: 'there would be one patch that replaces the pot-update target with the pot target directly'
<apteryx>were you thinking about to have dist: depend directly on teh .pot files rather than the doc-pot-update target?
<roptat>no necessarily, I was thinking about your change where you replaced the %.pot-update rule with a %.pot rule
<apteryx>yeah that ends up adding new code that is later removed, a good candidate for a squash
<apteryx>roptat: unrelated question: would updating the manual on version-1.3.0 be okay to mention how to get the new openpgp key required to check signatures on the 1.3.0 release archives, depsite the string freeze?
<roptat>apteryx, there is also a proposed change to update the manual to mention the .iso (as opposed to the .iso.xz). As long as you change only examples, @code, @url etc, fragments I should be able to do the change manually in the po files even if I don't know the language
<roptat>so I'll try to force the update by pushing the updated pot and po files to the weblate repository (so I don't become an author of the files for other languages, I don't want to be bothered by someone finding a spelling mistake in the Korean translation :p)
<roptat>in the worst case, I'll update the files on weblate myself
<lfam>civodul, apteryx: I had done a lot of testing in advance of the original release date. Unfortunately, the coming week is very busy for me. I had cleared my schedule before that original release date, but of course this week filled up as a result
<lfam>Hopefully not too much has changed since then regarding the installer
<civodul>lfam: hi! yeah, that's what we get for being late :-/
<lfam>Except the bugs that were reported, of course :)
<civodul>heh, i'm sure your contributions are not lost :-)
<raghavgururajan>leoprikler: python-pycairo and python-gobject can go to staging right? Around 600 dependants.
<lfam>I'm nervous about the ungrafting but, like I said so many times, I picked the grafts that seemed safe-ish
<apteryx>roptat: I've applied the patch manually (not sure why it wasn't happy -- but I copied it from paste.debian.net by hand and tried with 'git apply', so there's place for mistakes), and I'm not wondering whether we should also derive info_TEXINFOS from the list of LANGS?
<roptat>mekeor[m], no idea, but you might have more chance with the mailing list (firstname.lastname@example.org), the first message can be delayed waiting for human approval, subsequent messages go through directly
<mekeor[m]>roptat: thanks, i just signed up for help-guix :)
<roptat>mekeor[m], you don't have to, signing up means you receive every help request, not signing up means you receive answers to the messages you sent (we put you in copy)
<jbv1[m]>Hi guix ! If I use guix environment --pure julia, and I source the environment-variables left over by a failed build, am I in an environment that is exactly the same as the one used by guix to build julia ?
<jbv1[m]>I say that because my package has test errors but if I start the tests manually in the environment they pass...
<civodul>apteryx: a blog post for the RCs seems a bit too much to me; there's the fediverse already! :-)
<davidl>whats the status on using snap or AppImage packages in guix? Is it usable?
<lfam>jbv1[m]: It's not exactly the same as the build container
<civodul>davidl: hi! i think AppImages are self-contained and are supposed to Just Work, no?
<lfam>The build container has an extremely minimal filesystem (you can poke around by adding commands like (invoke "ls" "-la") or (invoke "tree" "-a"), fore xample)
<lfam>Probably, the differences wont't matter very much for debugging build failures of new software like Julia, because new software is usually designed to be built in ephemeral containers, compared to old stuff
<lfam>You might need to read the code of the failing tests to understand what's going wrong :)
<apteryx>civodul: fair enough, to me also to be honest
<jbv1[m]>lfam: ok thanks. The test failing is due to a piece of c code in julia that set the locale to utf8. Strangely sometimes it fails.
<davidl>civodul: and yes, my understanding is also that they should "just work", except that they don't seem to for me.
<apteryx>nckx: perhaps you know this area well; would customizing /etc/environment when present instead of adding /etc/profile.d/guix.sh be a good idea? That way it works even for non-login shells (e.g ssh the-box some-command)
<apteryx>(in the context of the guix-install.sh script)
<apteryx>civodul: the guix-install.sh script still recommands instaling one of glibc-locales or glibc-utf8-locales; should we drop the later, as it often causes confusion?
<nckx>apteryx: We should be prepared to deal with (e.g. non-PAM) software that doesn't load /etc/environment, like we've seen with /etc/profile, but I think it's a good suggestion and ‘more correct’ over all. It's a bit dirtier to manage compared to a whole file. /etc/environment.d is a thing but I don't know if it's as widely supported as /etc/environment outside of systemd.
*nckx had typed a lot more but learns that HexChat has no ‘undo’ support, like, at all.
<civodul>apteryx: could it be 'install-locale' from (guix ui)?
<apteryx>alternatively the install script could install glibc-locales itself since most people probably don't want to be nagged about locales every command
<lfam>jbv1[m]: Ah, that's not too suprising, aside from the "sometimes" aspect of it
<lfam>Especially if you are working on a host distro besides Guix...
<roptat>apteryx, ideally, the install script could recommend (and ask permission to automatically do it) running guix pull as root and user, and install glibc-locales as both (and further setup steps that might be needed)
<apteryx>kperhaps the script could have a --unnattended mode that'd uninteractively do what most people will end up doing manually (downloading the gpg keys, installing glibc-locales, etc.)
<tissevert>lfam: I mean I'm working on my vim-solarized attempt: taking the feedback I got into account, I'd like to change the source to refer to the main solarized repository and not the «vim-only» clone
<civodul>roptat, apteryx: so i suppose we could recommend glibc-locales after all, though that'll have to be after the release
<civodul>the install script could offer to install it
<vivien_>civodul, I’m running out of disposable directories on my system x)
<tissevert>trouble is: the guix hash for the «vim-only» clone (which I already have, it's in the patch I've already posted) doesn't match what guix hash returns for its input now
<lfam>tissevert: Remember, Git repos contain every single revision of the repository. You have to choose the same revision as used by your package definition. For example, if your package was using the Git tag "1.2.3", you'd need to run `git checkout 1.2.3` before calculating the hash
<tissevert>so I'd like to know what I'm expected to provide as input
<apteryx>civodul: good, I'll look into a convenient '--yes' switch for the install script
<roptat>tissevert, if you gave a git URL, guix hash will download the thing as if it were a file on the web, and it will get a message saying something "this is a git repository, not a website" or whatever
<lfam>Here is what Guix does when it downloads a Git repo to create the source code for a package. 1) It clones the repo 2) It checks out the value for "commit" in the package definition 3) It calculates the hash something like with `guix hash -rx`
<nckx>tissevert: Don't stop now, I still have popcorn (and am following along in a terminal).
<lfam>If you follow those steps, you'll get the correct result
<lfam>"--localstatedir=/var" is almost always correct, and if it's not then you'll probably know that it's not
<roptat>rekado_, do you have anything you can share on the bootstrap simplification you were doing, or did you do nothing really worth showing?
<rekado_>roptat: I was going to just follow what stikonas outlined. It’s pretty simple.
<rekado_>I got no patches and I lost a lot of my git stashes when I accidentally deleted my git checkout…
<tissevert>yeah, it's stupid really, I had done it on my guix laptop, but now I was trying to do a simple build just to check it worked, like all the builds I do on my guix laptop outside the guix development environment and I expected it to work because I had install the guix command on this foreign distro
<vivien_>Can someone explain me how I should use read-response and read-response-body from (web response)? I have written the response and response-body to a file. I open an input port. I call read-response. On the return value, I call read-response-body.
<vivien_>I’m working on a response composed of 4 lines: