<roelj>Alright! Passing more memory solved the problem. <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 <zzappie>,use (gnu packages package-management) > (current-guix) > Boom! segmentation fault <leoprikler>ruffni, I think you might want to (string-trim-both arg) and add a newline after (~a) <iskarian>the libgo.so library produced by gcc compiled with --enabled-languages=go seems to contain a path to the libexec directory in out, is this reasonable? ***lukedashjr is now known as luke-jr
<pkill9>it would be interesting if guix had the ability for you to specify init system <pkill9>plus implement other init systems <Aurora_v_kosmose>That second part is vital for the first, given how much services are tied into Shepherd atm. <BlackMug>leoprikler its true icedove is not showing errors anymore, but not because it has been built but because its stucking at the build process <BlackMug>but its taking forever on ../ 'build' phase <BlackMug>anybody having icedove installed on his guix suffering from this? <BlackMug>and how to debug this (what is making it taking too long) <Aurora_v_kosmose>--verbosity=LEVEL and --log-file are probably someplace to start. Or --debug=LEVEL <BlackMug>i see, i want someone to try install icedove and if he has the same issue <Aurora_v_kosmose>My next distro is more likely to be Qubes than Guix directly, although Guix guest VMs certainly out of the question. <BlackMug>for surely i wouldnt west hardware on guix or unstable distros <BlackMug>i will remove icedove and install it again instead of upgrading it lets see what will happen <Aurora_v_kosmose>There was some member here who considered one day messing around with porting Qubes' tools onto Guix System, but that remains a project idea afaik. <apteryx>BlackMug: what do you mean 'for surely i wouldnt west hardware on guix or unstable distros'; do you consider Guix an unstable distro? <sneek>Welcome back apteryx, you have 1 message! <Aurora_v_kosmose>In theory Git are working on the SHA1 problem. So that aspect of security might ifnally get fixed. <apteryx>roptat: that seems perfect! I'll try it now. <BlackMug>tons of errors , i dont have hardware available which can handle guix resources consumption <BlackMug>earlyoom suggested but still not yet implemented by default <BlackMug>(i only have one strong hardware which can handle high resources consumption but i put it for qubes) <BlackMug>also not all of the packages available within guix <BlackMug>yeah same i dont want nonfree either, but even with free software packages only not all packages there yet <BlackMug>no , only qemu as far as my last time checked <BlackMug>you didnt tell me can you install icedove using guix? <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")). <iskarian>Hmm, is there a way to "install" a package I built with "guix build" for testing? <iskarian>Like, the specific store item -- it takes a loooong time to build <Aurora_v_kosmose>iskarian: In theory, if its definition didn't change since you built it, and you didn't gc, it should use the one you already built. <Aurora_v_kosmose>BlackMug: I've mainly been using those vms as dev boxes, without really installing any of the huge normal-user software stuff. <BlackMug>Aurora_v_kosmose i always on end user and how he feel thus i try to install almost always the default packages <BlackMug>like browser , mail client, drawing software , office...etc <iskarian>ah, I was fooled by it downloading all new dependencies: I didn't realize that the pre-inst-env would mean it would want all new deps <Aurora_v_kosmose>BlackMug: Yeah, in my case it's mainly Guile, ABCL, SBCL & whatever libs I happen to be working with at the time. <BlackMug>../ 'build' phase <- reached to this stage? <Aurora_v_kosmose>Nah, the part where I'm done patching & downloading all the nonsensical bunch of dependencies <BlackMug>you are using guix package manager on which distro? <BlackMug>i think for better helping the project is to use the official distro of guix <BlackMug>since you are a tester anyway and distro type doesnt matter <BlackMug>yeah something is fishy with current icedove <Aurora_v_kosmose>It seems to be in the list of "will be built" instead of "will be downloaded" <BlackMug>icedove/thunderbird has internal browser thats why maybe its needed to have ff like to build <BlackMug>the issue is not what is going to build or so <BlackMug>i had icedove working and installed fine before this latest version <BlackMug>but latest upgrade which comes with JSON bug <Aurora_v_kosmose>Because latest pull seems intent on rebuilding everything mozilla from scratch <BlackMug>yeah and from that time icedove cant be upgraded and currently nor installed <BlackMug>yeah then why we have icecat instead of FF lol <BlackMug>only thing i saw icecat complaining is the DRM support <BlackMug>why it will take too much long time on your machine? <BlackMug>i have installed icecat,icedove and many other software <BlackMug>your case seems more complicated than usual hehe <Aurora_v_kosmose>Or rather, it's using the same package version, but refusing to use the one it just installed from substitutes without issue. <Aurora_v_kosmose>So yeah... I guess you can forget having any fast testing response from me. <BlackMug>but dont you think its better to use guix distro and do stuff what comes by default <BlackMug>this will be more useful to report issues for guix devs <Aurora_v_kosmose>I kinda have all my testing managed via configuration management for basically my whole homelab. <Aurora_v_kosmose>And no configuration management software so far has built-in support for Nix or Guix <Aurora_v_kosmose>Allows me to easily nuke VMs and rebuild them, so I clean-test things easily. <BlackMug>i see, i dont go too far either but i use default stuff then i try find improvements,bugs..etc <Aurora_v_kosmose>But Guix-on-native would require me to implement a config management module set for it. <BlackMug>install guix .iso within VM isnt that easier? <BlackMug>better use qubes, your life will be much easier <Aurora_v_kosmose>I'm using configuration management to deal with a fleet of testing servers, for the most part. <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 <BlackMug>i hope you didnt take a look at it in 2012 , then yeah its name was torbox and many stuff changed <Aurora_v_kosmose>I didn't take notes. But from vague memory, I seem to recall the supported ISOs being for whonix versions much older than for xen & others <BlackMug>" I seem to recall the supported ISOs being for whonix" hmm there isnt any isos for whonix, what do you mean? <Aurora_v_kosmose>It seems to have been updated, although libvirt images are one minor version behind virtualbox atm. <BlackMug>yes this is no issue , as these are point release versions <BlackMug>user who will install the older version will just need to upgrade to the newest changes <BlackMug>also vbox had nasty bug which needed new release to solve it for new users when they download .ova <BlackMug>thus kvm is not effected and no need new release <BlackMug>anyway you scared me thought something really bad whonix outdated at <BlackMug>good, btw anything you see wrong just report it <BlackMug>i dont think you gonna be more annoying than me with reports but dont hesitate to report <BlackMug>anyway lets back at guix and icedove issue <BlackMug>im gonna open new ticket later for icedove issue on hanging on building <BlackMug>i will send you the ticket URL maybe commenting there better as im not here 24/7 <BlackMug>just complete the building and whenever we meet again tell me the results <vagrantc>hrm. linux-libre and linux-libre-arm64-generic are both trying to build the same linux-libre-5.11.18-guix.tar.xz ... <sneek>vagrantc, you have 1 message! <sneek>vagrantc, apteryx says: that was the original idea; now the idea is to no longer do our own deblobbing, simply fetching pre-cleaned linux-libre <vagrantc>apteryx: i'm fine with that. mhw will grumble but probably grudgingly accept now that others are doing the work <vagrantc>figuring out a caching proxy sort of thing for git repositories would really help out tremendously <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>not of guix, but arbitrary projects, notably linux(-libre) <vagrantc>i would also consider switching u-boot to use git if we had support for that sort of thing <Aurora_v_kosmose>I'm not sure how the smart git http protocol might interact with things like squid <vagrantc>but i guess you'd have to force guix-daemon to use the proxy ... although maybe there are options for that <Aurora_v_kosmose>My current setup requires deploying templates to all users on the relevant machines. <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. <apteryx>roptat: it works well! I've been testing your patch disabling PO updates, along other changes you suggested such as removing the doc-update-po target <apteryx>The result is no more updates to the PO files :-) I'll test some more tomorrow morning and push to the version-1.3.0 if everything looks OK <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 ***apteryx is now known as Guest15199
***apteryx_ is now known as apteryx
<leoprikler>As far as I know raghavgururajan is still working on the core and its dependencies, after that there will be apps <leoprikler>Rovanion: Have you tried putting all those packages into a texlive-union? <leoprikler>To me, it appears as though the union did more than the sum of its parts <Rovanion>leoprikler: As in: Define a package through a call to texlive-union and then create an environment with that --ad-hoc package. Nope, but I'll try. <leoprikler>where file.scm consists of some header + (texlive-union ...) <rekado>Rovanion: I know about all the LaTeX stuff :) <rekado>you don’t need to use texlive-union manually <rekado>there’s a profile hook that should do the right thing <rekado>the font maps are generated with the appropriate texlive tools, but these tools need to be able to find the fonts <rekado>the profile hook will generate a texlive configuration file, which you should use. <vivien_>Did I make an obvious mistake? Is it possible to do what I want? <leoprikler>vivien_, could you grep for XML_CATALOG_FILES in your ~/.guix-profile/etc/profile? <rekado>vivien_: the search path is registered with the libxml2 package. <vivien_>I’m pulling some upgrades to check with an up-to-date guix, and I need to download texlive again, so I’ll tell you in some time <rekado>so when you install that package into your profile, XML_CATALOG_FILES will be set. <vivien_>Ah so I need to manually install libxml2? <vivien_>Can I install it as a propagated-input? <rekado>vivien_: you can also do “--do-not-upgrade=texlive” <rekado>vivien_: I don’t know! I think it should have the same effect to add it as a propagated input — but I’m not sure. <vivien_>I’ve done a GC recently so even with --do-not-upgrade=texlive guix will download it again <rekado>I know that there is an old bug report about a quirk in how search paths work <rekado>just be prepared that you may have to install libxml2 into the profile <vivien_>Honestly XML_CATALOG_FILES is a weird search path, I’m not surprised there are problems <fnstudio>(has something changed in the guix TUI when one does a pull? i think i see some progress bars that didn't use to be there? it looks awesome!) <leoprikler>in particular, you no longer get the full store path <rekado>is there an extra newline between download lines for all of you? <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 <rekado>Rovanion: I’m working on your TeX stuff now. Your example document needs a few more packages. <roptat>tissevert, I don't control the server unfortunately, did you receive a confirmation email? <roptat>when I registered a fedora account, it sent me a temporary password that let me connect and change it to a proper one <tissevert>yeah, I got the confirmation, tried to register a password, but logging with it immediately after failed (it was still in the clipboard) *raghavgururajan wakes up and rubs his eyes <apteryx>vivien_: I haven't checked, but that may be the case on core-updates branch, where multiple texlive trees are honored by the default config <Rovanion>rekado: I've defined a bunch of guix packages for the missing latex packages, do you want a diff? <apteryx>roptat: are you comfortable with removing that doc-po-update target? <roptat>apteryx, yes, do you want me to send a patch? <apteryx>no it's fine I have one in my tree :-) <apteryx>I'll push to version-1.3.0 shortly; you can inspect it and if it looks good it'd be a good time to merge the version-1.3.0 branch into master <vivien_>I’ve finished pulling texlive, and installed libxml2, but still no trace of XML_CATALOG_FILES in .guix-profile/etc/profile <rekado>but your use of “trivial” here is often incorrect <rekado>because you won’t get the .sty files <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 <rovanion.luckey@gmail.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>uh, on three different machines, my ~/.cache/guix/checkouts now contains only last-expiry-cleanup <roptat>apteryx, not tested, but looks good <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 <rekado>Rovanion: the problem really is that the profile hook only does half of the work <rekado>I’m adapting the builder of texlive-union to generate the maps now. <bone-baboon>On a substitute server after building a package is there a command I can use to add that package to the substitute server's cache? <pkill9>i did not know that the digital ocean deploy thing creates an Ubuntu VM and installs from there, that could be done with vultr <pkill9>in some ways, guile is the real operating system, and 'guix' is just an application <apteryx>roptat: I just pushed your change to version-1.3.0! I'm very happy that this po problem has been resolved, thank you! <apteryx>ryanprior: I remember you wondering about this problem, ^ <rekado>Rovanion: I’m about to push a fix to the texlive profile hook, which should fix your problem. <roptat>apteryx, there's one last change I'd like to make in doc/local.mk, to try and prevent forgetting adding stuff to TRANSLATED_INFO in the future <roptat>and that will require some changes to the manual on master, it already invalidates some of the things I wrote in the new translation section <apteryx>roptat: by the way, the removal of xz compression for ISO images LGTM (with François' comment about perhaps adjusting the .po translations mechanically?) <roptat>yeah, although we should not do it directly in guix repository, I'll take care of that if someone pings me when it's pushed <roptat>(if we do it in the guix repo, chances are that next time we get po from weblate they won't be translated anymore) <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 <roptat>we'll have to run "make download-po" on version-1.3.0 before the release or next rc <apteryx>roptat: won't that pull too new translations? <roptat>no, I kept the pot on version-1.3.0 on weblate <roptat>I froze weblate until we release, then we'll start tracking master again <apteryx>OK. It'd be useful to have some document explaining the translation process, especially in relation to releases <apteryx>perhaps on the guix-maintenance repo, under doc/ <apteryx>it could be linked from doc/release.org <roptat>I'd prefer to convert all these documents to the manual, so it's easier to find, and a bit more public (transparent?) <apteryx>it's OK to keep it there then, and we can link to that section from release.org <apteryx>roptat: hmm, I applied tho ISO patch, tried running 'make', then got: ./doc/guix.pt_BR.texi:165: @menu reference to nonexistent node `Contribuindo' <apteryx>I'm pretty sure if I 'git clean -xfdd' it'll build fine, but why would that be <roptat>I'm not sure why, but it seems we have some weirdness going on because TRANSLATED_INFO was not kept synchronized with info_TEXINFOS <roptat>hope it works... in the worst case, remove doc/guix.pot_BR.texi and run bootstrap, that should be enough <pkill9>nice, they're gonna add non destructive stackable effects <apteryx>roptat: hmm, are there other commits under it depends on? It doesn't apply on version-1.3.0 <roptat>apteryx, uh? I just pulled version-1.3.0 and made the changes directly on that branch <roptat>it's a patch on top of f13049f3a856d842fee1abb50e61481b891f2020 <mekeor[m]>which chapter of the manual describes how to run a docker container as a guix-system-service? <vivien_>pkill9, I see that you’re talking about musescore, do you have audio in musescore? <pkill9>i just tested it and i don't hear anything <civodul>apteryx: looks like we're not getting too much feedback for RC1 *vagrantc wires up a microphone to a speaker <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. <leoprikler>almost 700 on pygobject as far as I can see, but in a vacuum yeah <leoprikler>the question is whether an update relies on newer cairo/glib <leoprikler>if it builds with staging's glib and proper review is done, go ahead <leoprikler>well, it should also run fine, but I trust GNOME people to have reasonable testing in place <apteryx>civodul: No news is good news, they say. <apteryx>lfam: the branch has been frozen for a while, I'm sure your testing still applies <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>apteryx, no I tried, but it ends up creating a Makefile that doesn't recognize $(foreach as a valid texinfo extension :p <roptat>meaning, the generated Makefile somehow doesn't expand the variable <apteryx>civodul: a way to attract more testers could be to have a blog post for the RCs <ruffni>thanks! "guix search math.h" or "guix search c-library" (or the like) didn't really help... <apteryx>not sure if that's worthy of a blog post, but I guess it could help <roptat>yeah, "guix search" doesn't know about the files in packages <ruffni>i would eventually have found it, but for "gnu c library" there's 164 hits (it's 4406 just for "c library"). so thanks again! <pkill9>what's the difference between openjdk and icedtea? <roptat>icedtea was a project to add a build system around openjdk, until jdk8. Since jdk9, openjdk has a its own build system, so java <= 8 is icedtea, java >= 9 is openjdk <roptat>icedtea 1 to 3 corresponds to java 6 to 8 <stikonas>roptat: openjdk8 also has build system, icedtea3 is not necessary for java 8 <stikonas>although, it might be needed for other reasons (not build system related) <stikonas>e.g. if icedtea 2 can only build certain version of icedtea 3... <roptat>I think it's historical, we had icedtea 1 and 2, then went to icedtea 3, and openjdk didn't have an icedtea, so we switched to it <stikonas>I'm not sure if all java 8 versions have openjdk build system <stikonas>building icedtea 1 is probaly historical too <roptat>not sure what it would bring us, but at least it means rebuilding every java package, which is not great <stikonas>jamvm is in priniple capable of building icedtea 2 <roptat>oh, if we can get rid of icedtea-1 that would be great <stikonas>roptat: I don't have any guix code for that, but I have gentoo overlay that builds icedtea 2 directly <stikonas>(I had to build newer ecj first than what would be necessary for icedtea-1, but building ecj is quicker <roptat>I think rekado_ was re-working the java bootstrap at some point <roptat>I don't think I have enough time to work on this to be honest <stikonas>yeah, I think I briefly talked to rekado before... <stikonas>but yeah, these big changes are often hard <roptat>but if you can show us the exact build order, I think it would be worthy of a bug report <roptat>with the "wishlist" tag or whatever it's called <stikonas>well, the only thing I replaced was (icedtea1 with patched ecj-4.2.0) <stikonas>other than that it's the same thing as what guix does <roptat>there's a comment in guix sources: Version 3.2.2 is the last version without a dependency on a full-fledged compiler for Java 1.5. <stikonas>maybe @Override can be done in a nicer way in java vm <stikonas>yeah, shouldn't be too hard to port if once knows guile better than me <roptat>mekeor[m], no idea, but you might have more chance with the mailing list (help-guix@gnu.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... <roptat>you'd need to be in a container too <roptat>and I think the environment is slightly different, because I've seen build environments like that not behaving exactly the same <vivien_>With --container, the programs have access to HOME <vivien_>Within a build environment, they don’t <vivien_>(or they can write things to some place called HOME) <jbv1[m]>and do I need to expose or share some paths of the host file system ? <roptat>no, I think the build container is more strict than what --container already does <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 :) <davidl>civodul: When trying to execute an AppImage executable I just get "no such file or directory" <drakonis>civodul: they didnt seem to work all that well under nix <drakonis>its that it expects the linker to be on the default location it seems? <apteryx>hmm, just like the regular ~/.profile is not sourced for non-interactive shells, /etc/profile.d/guix.sh also isn't correct? <drakonis>is there anything besides rolling out my own setup for mutable system containers available right now? <drakonis>for building a development outside the trappings of guix <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? <civodul>davidl: ah it could be that AppImages hardcode the dynamic linker name, /lib/ld-linux*.so <civodul>you could work around it by providing your dynamic linker under /lib, but then warranty void <civodul>apteryx: looks like guix-install.sh doesn't recommend anything, does it? <apteryx>oh, indeed, it comes from somewhere else <apteryx>I'm pretty sure at the end of using the guix-install.sh script it prints something about locales, but that's probably Guix itself <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)? <nckx>Every diamond has its perfect flaw. <apteryx>civodul: yes, that's the only hint that includes it <civodul>it does mention both packages, but i guess most users understandably just copy/paste <apteryx>the example that unnattentive readers will copy paste contains glibc-utf8-locales ;-) <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.) <lfam>Definitely not "uninteractive" :) <apteryx>that's already yes | ./guix-install.sh <roptat>mh... won't work for downloading the gpg key though <apteryx>ah, right. So a dedicated switch still makes sense <roptat>yeah, the name doesn't matter much :) <civodul>roptat: i think it'd be confusing to automatically run "guix pull": you install 1.3.0 and at the end of the process you find yourself running 1.7.0 <civodul>but again, glibc-locales is a huge package <apteryx>unless you use file system compression I guess <apteryx>I was thinking about bandwidth considerations <roptat>could the script automatically detect locales and install just them? <roptat>mh, maybe not, updating will be tricky <roptat>wait, don't we already install the required local in the first profile? <lfam>Isn't it like 1GB uncompressed? <tissevert>I never get what I expect and my first build attempts systematically fail because of the hash <lfam>What do you mean tissevert? <civodul>that must be full of zeros or something <vivien_>Same for me, I gave up some time ago and now to hash something I just paste nonsense in it and wait for the failing build to give me the correct hash <lfam>We are happy to help explain how to use `guix hash` <vivien_>The problem is with uncommitted files, they influence the hash <vivien_>It’s not really easy to detect them and ignore them <tissevert>vivien_: I could do that expect I have trouble building on this foreign distro because apparently I haven't set my GUILE_LOAD_PATH correctly <lfam>That's true. You need to run it on a "clean" copy of the Git repo vivien_ <tissevert>and so I'd like to be able to predict it since I can guix hash but not guix build <roptat>civodul, it is indeed full of zeroes <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 <apteryx>civodul: using Btrfs zstd compression, checking with compsize I get: TOTAL 33% 72M 215M 937M <tissevert>I suppose it is what guix hash would've returned and I check : it is indeed the case <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 <lfam>Does that sound relevant tissevert? <nckx>tissevert: Did you run ‘guix hash’ with ‘-rx’ and is your own checkout pristine? ‘guix hash’ looks at all files, even ones not tracked by git. <lfam>I am telling you that you should check something out with git :) <tissevert>I've sent the retrieval URL directly do guix hash <civodul>apteryx: i was commenting on the glibc-utf8-locales/glibc-locales install, but i have nothing against --yes :-) <nckx>tissevert: Uhm. I don't think that's even supposed to succeed. <lfam>By default, when cloning a Git repo, it "checks out" the latest revision. If you are building a different revision, you need to check that revision out <nckx>tissevert: How did you do that? <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 <nckx>roptat: It just says ‘no such file or directory’, it's not network-transparent. <tissevert>looked at the release links, mainly tarballs with a proper tag <nckx>tissevert: I think you went to great lengths to hash the wrong thing :) <tissevert>but underneath there was also a link for the corresponding commit <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>It doesn't matter which you choose <tissevert>no smart thing to reach directly the right commit ? <nckx>tissevert: It doesn't matter, -x ignores .git altogether. <leoprikler>shallow vs. proper shouldn't matter, .git is excluded <lfam>The important thing is to be able to checkout the value for "commit" in the package definiton <apteryx>nckx: re environment.d, I'm guessing we could just check for its existence, and add our config there if it exists, else fallback to profile.d <tissevert>(I like it when tools do the simple thing you'd expect them too, I've become too used to ugly things always hiding stuff) <lfam>The "-rx" means "--recursive --exclude-vcs". The "--exclude-vcs" ignores the .git metadata directory <tissevert>lfam: nckx vivien_ and of course it works !! <leoprikler>Don't say that too loud, we get a lot of requests of "why doesn't this do [complicated thing], it's not user friendly!" <lfam>Thanks for bearing with us in our rush to explain <lfam>As we piled on top of each other to help :) <tissevert>thanks for bearing with me for the overlong explanation of what I was unnecessarily trying to achieve ;) <nckx>apteryx: That will complicate debugging (just a bit, but death by paper cut & all that). Many people trying to help won't even be aware of the fork in the road taken long ago by a script. <nckx>Can't we just do always install both, and write profile/guix.sh in a way that's (or tries to be) idempotent? <nckx>This is fun. Much as I loathe ‘idea men’ on the ML it's easy to play one :) <apteryx>nckx: I guess that could work too; /etc/environment.d/guix should happen before /etc/profile.d/guix.sh, so the later can check if things have already been set and do nothing if it was <nckx>‘Temporary test directory at /tmp/guix-build-bitcoin-core-0.21.1.drv-0/test_runner_₿_🏃_20210503_200024’ still gets me. Rocket emojo in Guix test suite when. <nckx>...it's not like we already have locale issues... <nckx>apteryx: That's my understanding. <nckx>But seriously, thank you for actually and finally taking care of this. <lfam>I can't believe the bitcoin people did something unreasonable... ;) <vivien_>What if you find a file name with unicode encoded in UTF-16 though <lfam>What if the blockchain collapses because of a ASCII / UTF-8 string handling bug <nckx>Everyone gets free bitcoin? <lfam>Only then will money be free <nckx>(Also, allow me to interject, you actually mean ‘gratis’.) *nckx adds that one to the test suite, too. <rekado_>stikonas[m], roptat I had been meaning to simplify the Java bootstrap, but … you know how it is. <rekado_>but I’m happy that one of the distractions turned out to be very productive; the modular texlive now builds font maps, so pdflatex works as expected. <roelj>So, is it expected that running an nginx service in a Docker container simply doesn't work? :/ <roelj>If I run the same configuration as a VM, nginx seems to start <rekado_>you may need to tell Docker that you need extra permissions <nckx>If it has something to do with ports, I think so, at least by default. <roelj>rekado_: Is that also when I bind to ports higher than 1024? <roelj>rekado_: Yeah, I'm binding port 8000. But I don't know how to debug it anymore <tissevert>I'd really like to build to check I haven't messed everything up, seeing as I ended up using a reference to a particular commit <tissevert>but I can't search or build from my checkout of the guix repos <roelj>rekado_: If I go inside the container, there's no nginx process running and the log files are empty <rekado_>tissevert: use ./pre-inst-env guix build … <lfam>Why is that tissevert? What goes wrong? Did you follow the instructions in Building From Git and Running Guix Before It Is Installed? <lfam>Setting GUILE_LOAD_PATH is not part of those instructions... <lfam>(It's handled automagically by the pre-inst-env script) <tissevert>I was trying to do the same as what I did when I was on my guix system when I drafted the package <nckx>tissevert: If you're using ./pre-inst-env, you still need to be in your ‘guix environment guix ...’. <tissevert>simply use guix build to check my guile expression was correct <lfam>Once you have the development environment set up as described in the manual, you can use all the Guix commands, but based on your development repo, with `./pre-inst-env guix ...` <lfam>So, `./pre-inst-env guix search foo` and `./pre-inst-env guix build foo` *rekado_ updates CRAN packages… <lfam>Concretely, this means entering a development environment with `guix environment guix` and then doing `./bootstrap && ./configure --localstatedir=/var && make` <lfam>Then, you'll have the pre-inst-env script <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 <roptat>rekado_, I see, then I might try that out if I don't have anything else to do :) <stikonas>anyway, I haven't touched java for some time... <stikonas>by the way, speaking of bootstrapping, Mutabah's mrustc (latest git, not yet released) can now bootstrap rust 1.39 <nckx>Grr. Putting ridiculously low timeouts in a test suite is such a Bitcoin thing to do. ‘lol ur not using the test suite ASIC’ <civodul>rekado_, cbaines: wouldn't public-inbox simplify the implementation of Mumi and Patchwork or Patchwork-like automation? *civodul just cloned a public-inbox for the first time <nckx>tissevert: Thanks for the report! <jbv1[m]>so I use guix environment -C julia to inspect the failed build directory of julia with a similar environment as the build process <jbv1[m]>but strangely the paths in the environment-variables file do not match the paths in /gnu/store of the environment <tissevert>ok, ./pre-inst-env guix search vim-solarized gives a weird error (« <tissevert>In execvp of less: No such file or directory») <nckx>tissevert: Is PAGER set in the environment? <tissevert>I'm way to tired to fix this tonight, so sorry but I'll look into it tomorrow <tissevert>frankly I don't know, this other host is a real mess and I have no idea what is correct or not here <nckx>running ‘PAGER= guix search ...’ should work. <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: <vivien_>It seems that the Transfer-Encoding header messes up something <vivien_>When I called write-response and write-response-body to generate the file, the Transfer-Encoding header should have been discarded <mroh>nckx: thank you for adding a comment to vcsh (and removing #t ;) <aecepoglu[m]>In importing a `go` module, do I use the same path as I would in `go get` ? <nckx>mroh: Thank you for ‘testing’ our chess packages. *jonsger thinks that nckx has a huge keyboard with very special keys :P <cybersyn>i've hit my first serious headache with guix that I can't figure out, its something I imagine there is a simple answer to but i'm still not gathering anything <cybersyn>i'm trying to reconfigure my system specifically with a grafted package, because without the graft the kernel won't load the modules (it seems) <cybersyn>I can download it using the --with-graft option and it builds fine. but when i reconfigure, it goes ahead and downloads the original, tries to build that, and fails <nckx>But now I'm armed with nothing but a browser and poor taste. <cybersyn>i've experimented with options->transformation and package-input-rewriting, but can't get them to work from inside my config. any help would be appreciated :) <nckx>Can you share the error message(s) through paste.debian.net, cybersyn? As well as the (decompressed) .bz2 build log if one is mentioned. <cybersyn>sure, but just a warning there is nonfree drivers in there so want to make sure it wouldn't be breaking the rules <nckx>Meh. I don't think that counts as promotion. Only if the error is caused by them is your warranty void. *nckx :q for a while. Will return. <nckx>(Others may disagree with me about the non-free stuff in my absence; my opinion is just that.) <cbaines>civodul, public-inbox isn't something I've heard of before. Regardless, I think the main limitation is that people often don't submit patches in a machine readable way <civodul>cbaines: yeah, attached, inline, format=flow, and all that :-/ <civodul>public-inbox does look pretty fun tho 