<zacchae[m]>reading the user manual. guix weather only checks enabled substitute repos anyway, so something is strange here. linux-libre for aarch64 comes up for me, yet it is still trying to build it. I wonder if it is related to the fact that guix system init is building multiple linux-libre-5.13.12-guix.tar.xz.drv with different hashes <civodul>zacchae[m]: "guix weather" does not use the list of substitute URLs that guix-daemon is using <civodul>it could be that guix-daemon uses only ci.guix (the former default) and "guix weather" checks both <iskarian>Any hot takes on installing LICENSE files in /share/doc/package instead of /share/doc/package-version? <iskarian>(Since most packages install their docs in /share/doc/package) <nckx>There are quite a few that install them to package-version, so it would be churn either way, but SGTM. <nckx>Better one location than two. <iskarian>The only potential sticking point is that in theory license could differ between versions, so if you install two different versions of a package, there could be a conflict. <iskarian>But I guess there would be a conflict in that case anyway. <nirnam>Hi, I used guix in a package manager on my gentoo system, after symlink guix-profile to my user and now doing guix package -i hello to test it out, it seemed to be pulling down every packages in the repo right now, is that normal? <sneek>nirnam, leoprikler says: you need bluetooth-service-type in /etc/config.scm (assuming Guix System) <nirnam>did that, trying it out as package manager for my main system right now, so far shephurd has not been working out for me <dstolfa>nirnam: pulling every package sounds like it shouldn't be happening. it may just be pulling down some dependencies that the package needs to run (guix doesn't use system dependencies, it uses its own) <nirnam>I would guess that too, because hello package should be needing perl, acl, m4, gawk, help2man etc .... <nckx>Calling build dependencies 'every package in the repo' is strange hyperbole coming from a Gentoo user ☺ <dstolfa>nirnam: also, could you elaborate a bit further on what problems you had with shepherd? <nckx>nirnam: Correct, you need them to build things. <nckx>nirnam: If you want to download prebuilt packages (when available), make sure you've set up and authorised the substitute servers. <nckx>See 'Substitute Server Authorization' in the Guix manual. <nckx>Guix will always transparently fall back to building from source, though. <dstolfa>nckx: btw i didn't forget about `guix bisect`, i just barely have time to eat right now... $WORK + moving turns out to be very time consuming <nirnam>ah that might be, I saw that as optional so I skipped it, note on gentoo it have every thing it need to build stuff and base system in stage3 zip file <nirnam>so you don't really need to install the build system from portage when installing it <nckx>If ‘it’ means Guix here: Guix is self-contained by design, it will not re-use whatever build tools you have lying around it. Strict isolation & control of 'build inputs' is core to how functional package management operates. <nckx>nirnam: Guix has a much smaller (tiny!) set of 'bootstrap' binaries but builds as much from source as possible. <nirnam>by it I mean gentoo, I was talking about how gentoo getting their base system setup <nckx>Right. They just ship a huge set of binaries IIRC (it's been years since I've used a Gentoo-derived distro), but if you use it long enough it will be all but replaced by newer build tools you did build yourself, no? <nckx>Like stage 3 will contain a GCC 9 binary, but when 11 hits the repos you'll build it at home. <nckx>Guix just does all of that up front, (almost) from byte zero, although there's still some way to go. <nckx>dstolfa: Take your time. <nirnam>I'm gonna get substitute server authorization setup, I was going for using guix as binary package manager in place where building it doens't have any benefit <dstolfa>nckx: my girlfriend makes sure of that! *dstolfa is looking forward to finishing up a lot of stuff to get some more time on his hands... <nckx>They do tend to do that. <nckx>dstolfa: And all you need for that is more time, right? Easy. <dstolfa>i need more workers in my worker pool, currently there's only one and he seems to be deadlocked on this task called: "finish phd" with random pre-emption to handle minor garbage collection tasks *dstolfa will now stop with the dad jokes before it gets out of hand <nirnam>< nckx> Like stage 3 will contain a GCC 9 binary, but when 11 hits the repos you'll build it at home; that is right, but to be fair you do need compiler to build a compiler <dstolfa>i'm trying to take a tool like dtrace/ebpf (for tracing purposes) and make it look at VMs in a way that allows you to program it, rather than just get data and process it after-the-fact <nirnam>guix seemed to be working fine now, looking forward to this <dstolfa>well it already works, but now i have to get some numbers, make some pretty graphs, automate all that and write a pretty looking dissertation and hopefully paper <nckx>(Cheap, but I couldn't resist ☺) <nckx>dstolfa: OK, interesting. I've certainly never used eBPF but I'd always thought it... was... that. <zacchae[m]>it only give instructions for how to retrieve it on GuixSD <dstolfa>nckx: yeah i've always found that very few people use such tools, but those that do really appreciate their existence. i guess more people use eBPF since it's more general in the sense that it implements parts of LSM, XDP and so on <nckx>zacchae[m]: By which I mean, open it in a Web browser. <nckx>In fact that applies specifically to non-Guix Systems. <nckx>...for some reason I had read the word 'manual' somewhere in your messages where it literally never occurs. Indeed, the bordeaux landing page could use a link to it. <nckx>But the short version is: $ sudo guix archive --authorize <nckx><paste key from that page> <bsturmfels>question on patchset etiquette - civodul suggested sending a V2 of the patchset in https://issues.guix.gnu.org/49993 - do I do this by changing the patch subject to include "V2" and resend the patchset to that bug, generating ~ 10 emails? <nckx>‘It depends’? If you change more than 1-2 patches, I do recommend just sending the whole series again with git send-email -v2 or whatever. <zacchae[m]>oh, is #7D602902D3A2DBB83F8A0FB98602A754C5493B0B778C8D1DD4E0F41DE14DE34F# the entire key? I was under the impression that that was an identifier used to fetch the key from a keyserver. In that case I am fine. Do I include the '#' on either side? <nckx>Elliptic keys are tiny. ☺ <nckx>(Since you mention keyservers: it's not a GPG key.) <zacchae[m]>thanks, though I'm pretty sure the NSA has a backdoor for elliptic keys <nckx>bsturmfels: If it is just one or two, replying with a V2 to only those two messages is also OK (again IMO). <nckx>Like, literally, all elliptic keys? <zacchae[m]>nckx: Not every one. Probably the Dual EC DRBG at least <zacchae[m]>I see now that there are many implementations that have come up after the possible back doors were noticed, so I trust that Guix is using one that is not compromised <nckx>Well, sure, I'm not advocating the NIST curves either, but 'backdoor for elliptic keys' sounds 2FUDdy4me. <nckx>zacchae[m]: Ed25519 is widely considered one of the probably-not-backdoored ones. <nckx>But that's all we can say. <zacchae[m]>Wow, I'm really glad I added the substitute aarch64 server. Seeing how far it has gone now, it probably would have taken ANOTHER full day to compile for aarch64 on a raspberry pi 4 <nckx>I just finished building both linux-libre .tar.xz's on ci.guix. <nckx>Because I was curious ☺ Diffoscope is still running on both. <jab>hey guix! I just got my pinephone. Phosh/gnome works pretty cool. It took me just a few moments to set up jmp.chat. <jab>TRying to get mint mobile to work now... <nckx>Hi jab! I saw your mail. Great news. <zacchae[m]>Oh wow, running GuixSD? Phone and text works fine? <jab>zacchae[m]: It's running postmarketOS. <jab>I offered to give ssh access to guix developers two nights a week. <jab>zacchae[m]: I have gotten texting to work over wifi. I have not gotten calls to work over wifi yet (I just got it yesterday). I hope to get SMS and satellite calls to work soon. <nckx>Porting Guix System to the Pinephone in a day would be nice why didn't you do that jab. <jab>nckx: You do realize I'm not even close to half the developer you are right? <jab>But I appreciate the compliment. :) <zacchae[m]>jab: Oh, is there a need for that among guix developers? I might do similar when I get my Librem 5 (whenever that happens) if it helps <jab>zacchae[m]: I've no idea if it is a need or not. :) I just thought I'd offer. <nckx>Knowing how much of a developer I am that's highly disturbing and probably untrue. <jab>zacchae[m]: I really want to try out the librem 5 too. On an unrelated note, may I borrow $2000 USD? <nckx>It's a super generous offer but I wonder how useful SSH access is. OTOH better than nothing. <nckx>‘jab, I broke it again, could you reboot’ <zacchae[m]>I was under the impression that the pinephone needed blobs and so wouldn't run a free OS, though I guess the free software community be wildin <jab>nckx: I've seen your code! It would make an MMA fighter weep. All I've offered guix so far is documentation things. :) <jab>zacchae[m]: That is correct. There are 3? blobs I think? The modem, wifi, and maybe the SIM card? <nckx>Documentation's super valuable in a world where there's far too little of it. <jab>There is some work to "free" the modem via software, but you'll have to flash it yourself. And they may not be legally allowed to sell devices with the "free" software running on it. <jab>nckx: gotcha. good to know. :) <jab>I don't even know what the package manager of postmarket OS is yet... <jab>I might switch to Debian or PureOS for the phone. Not sure yet. <nckx>Are there any blob-free mobile telephones at all? I thought they simply didn't exist. *nckx gestures vaguely, waving around words like 'baseband', despite not owning any phones. <nckx>zacchae[m]: Cool, I'll have to read up on it. <zacchae[m]>they filed for some exception with the free software foundation (which they granted) to have the Librem 5 endorsed. Basically, there is some blob that get's executed, but it is off the main device <jab>nckx: You are correct. I think that the librem has some blobs, but they are pursing RYF. <nckx>TBH the only association I currently have with ‘Librem 5’ is ‘people on Reddit complaining it hasn't arrived yet’. <nckx>And I mean only: I thought it was a laptop. Oops. <jab>ALSO, I think that the librem may have freed the firmware/software for the wifi card...They paid some company to do it for them... <jab>nckx: It is taking a while for it to arrive. BUT they are writing most of the software that pinephone users use. Including me. <jab>They wrote libhandy, phosh, etc. <zacchae[m]>nckx: Purism is a small and new company. They are slow, but they are the only company in the game. The phone ships with PureOS, which is one of the only FSF endorsed OSes <jab>zacchae[m]: I actually want to invest in purism. <nckx>Yeah, I'm sure Purism has their share of flaws but they get a bit too much flak from the popcorn gallery to my liking. <jab>They are currently raising money...but you have to have 1 million in assets or make $200,000 a year to do it. <jab>anyone wanna invest on my behalf? :) <nckx>'We are trying to do $impossible_thing’ ‘Cool here's my money.’ ‘It might take more than a month?’ ‘OMG SCAM’ <zacchae[m]>jab: I did, and you still can (not sure if I'm allowed to post such a link here) *nckx .oO Why not? (Genuine question.) <jab>zacchae[m]: Are you an "credited investor"? eg: Do you make $200,000 in a year or have $1,000,000 in assets? <nckx>jab: That sounds like shorthand for 'being an accredited investor in the US’. What about the rest of the world? <jab>nckx: I'll post a link ...just a second... <zacchae[m]>I was able to invest, and I don't have shit in assets <jab>zacchae[m]: You may have been able to "invest", but you may not legally be allowed to do so. Just a heads up. It's written in the fine print of the website. <nckx>It's nice that there's a $1000 increment option for the plebs. <jab>zacchae[m]: It's more for their legal info...but the U.S. government may have questions when you do taxes next year... <nckx>It's really not that rare that they do. <jab>I know a few credited investors. I'll just ask them. <nckx>And if Purism printed it too finely, they are on the line, so I'm rather surprised you said that. <zacchae[m]>Not that I endorse the totally not legal thing I did by accident <jab>zacchae[m]: hahaha. honest mistake. :) *nckx looked at the print and it's in the same size font as the rest of the page, phew. <zacchae[m]>nckx: the text was not finely printed, but the invest button was above it, so I just pressed the "GIVE PURISM MONEY" button as soon as I saw it <nckx><I don't have shit in assets> <nckx>Someone hit refresh too often. <nckx>You can throw away the phone and live in it. <nckx>Or sell the phone to buy a bigger box? <zacchae[m]>I'm kind of a minimalist, so I'll take a box so long as it keeps my Librem Mini 2 safe <jab>I'm a minimalist too. <zacchae[m]>also lol Purism's goal was 3mil, and they already passed 9mil <jab>does anyone know how to set up calls in gnome/phosh to use my SIP account? <nirnam>I have seen a few funny thing scrolling thru my initial guix install, I understand that it will install build tool for me as it needed to build thing later on, but which part of build process of the package hello required curl and libjpeg-turbo? <nckx>I don't know enough about Guix/ARM to know why that is but it seems insanely suboptimal. <nckx>nirnam: There is no direct connection between hello and libjpeg-turbo, but it could be an input to your ‘profile’ (the ‘environment’ into which Guix installs packages). <zacchae[m]>yeah, so wait. It builds both then checks if I have a pinebook and boots that one? Very confusing. I do care in as much as I want to make sure the weird behavior is known (like a good beta tester) <nirnam>That might be, I'll try to trace these package later, anothor thing I noticed, it sometime downloading the same package twice, why is that? <zacchae[m]>also jab , you mentioned 2000$. Just making sure you know that only the Librem 5 USA is 2000$. The Librem 5 (not USA) is "only" 900$ <jab>Well I am making a phone call via mint mobile now... <jab>I think it re-routed me to the mint mobile team...maybe? <jab>It said ultra mobile. <jab>zacchae[m]: how much does shipping cost on the chinese made Librem 5? <jab>apparently mint mobile is owned my ultra mobile... <jab>I am so surprized. "Calls actually works!" <jab>again, the SIM card is not activated yet... <zacchae[m]>I got free shipping with mine. I ordered mine back in February though <zacchae[m]>and I was kicking myself for not buying one when it was "only" 700$ <jab>Well callso totally works! <jab>I called the mint mobile people and they turned on my phone. Very cool...the only downside is it seems like I have to download the app to use mint mobile... <jab>So I'll probably have to go look for a different carrier tomorrow. <zacchae[m]>Anyone know if the normal u-boot bootloader works for a raspberry pi? <zacchae[m]>More importantly, has anyone gotten GuixSD running on a raspberry pi period? <zacchae[m]>I figured it would work fine because I am running it wired and headless, and I already have it running aarch64 <xd1le>unavoidable carrier app... brilliant <apteryx>it's cheaper than what Apple asks, too! haha <zacchae[m]>jab: you could always get AweSIM if you want a carrier that works with FOSS <zacchae[m]>apteryx: I definitely see Purism as a libre Apple <nanounanue>I am trying to fix an issue with the emacs-org-roam package. When they upgraded to version "2.1.0", the Org-roam developers moved some code to the "extensions" folder. I would like to contribute fixing it (since I am a heavy user of org-roam), but I am not able to figure out how to add those files to the recipe <nanounanue>I am able to build the package, but when I check the output, I am not able to find the "extensions" folder <nanounanue>(I was able to reach this point with help of daviwil, but I am stuck) <nanounanue>Looking into the MELPA package, all the files from the extensions folder are copied to the main directory <nanounanue>In my code (wrongly) I was creating a file "extensions" and copying everything there <nanounanue>But actually, I should copy every single file from extensions into the "main" org-roam directory <nanounanue>The only thing that is wrong is that "org-roam-2.1.0" (line 29) is hardcoded <zacchae[m]>it looks like version gets set to just that string. How about (concat "/share/emacs/site-lisp/org-roam-" version)? <zacchae[m]>or whatever guile's string concatenation function is <nanounanue>zacchae[m]: The correct method in guile is `string-append` <nanounanue>But the variable "version" is out of scope (apparently) <nanounanue>but if I use (string-append "/share/emacs/site-lisp/org-roam-" "2.1.0") <zacchae[m]>`(string-append "/share/emacs/site-lisp/org-roam-" ,version) <nanounanue> (string-append "/share/emacs/site-lisp/org-roam-" ,version) <zacchae[m]>I've never needed to use backquote expanding, but I think that should work <zacchae[m]>it was because you had it inside of a lambda expression, so it was being evaluated in a different scope <zacchae[m]>Also, in case anyone was wondering, it seems the raspberry pi is not yet supported for GuixSD. Someone packaged rpi-open-firmware, but from what I've seen, no one has gotten it to boot except through netboot. However, my sense is that support is just around the corner. <dhruvin>I'm building a guix image for sourcehut builder. It's almost complete now. <dhruvin>How do I specify that I need to produce a file at "/home/build/.gitconfig" location, in a "operating-system" definition? <dhruvin>I tried using "extra-special-file". But that made the "/home/build" directory owned by "root" instead. <bricewge>dhruvin: Do you have a unix account named "build"? <bricewge>If so you could that .gitconfig in /etc/skel/, so that when the account is first created you end up with /home/build/.gitconfig. <bricewge>However this file will be created for every user account, not just "build" <bricewge>To do that properly (ie. just for /home/build/.gitconfig) you would need to write a shepherd service creating that file <bricewge>For the "skel" hack you would need to put that in the "skeletons" operating-system field <dhruvin>I have never created a shepherd service, but I've read their docs. I'll go for that hack first, for initial draft. <dhruvin>I'll replace that hack with said shepherd service. <dhruvin>I'll get back to it, thanks again for your help. :) <mange>bricewge: Are you sure you need a shepherd service? Couldn't you do it by extending the activation service? <bricewge>You're right it probably make more sense to extend the activation-service that shepherd-root-service <dhruvin>Okay, I'll extend the activation-service instead. Thanks mange. <bricewge>mange: Actually the creation of user account is done in a shepherd service, so the activation service will run before the creation of the account <mange>It looks like the accounts are created during activation (see account-activation in shadow.scm, which is run at activation time) and the home directory is created by the shepherd service (see account-shepherd-service in shadow.scm, which defines a one-shot service). Unfortunately this might mean that you still need to run after the shepherd service to properly create the file. <bricewge>So doing that in the activation-service, you need to create the home for the "build" user yourself during the activation which would prevent "account-shepherd-service" from creating a usual home with skeletions and such <dhruvin>update: skeletons hack suggested by bricewge worked. Now reading about creating/extending services. I'll have to extend "account-shepherd-service" to add said ".gitignore" file, right bricewge? <bricewge>dhruvin: Yes, but you will need to take extra steps if extending account-shepherd-service since the home for "build" won't be build by account-shepherd-service <attila_lendvai>so, i have downloaded the official geth (go-ethereum) release binary, and ldd output looks reasonable, .so's resolved to /gnu/store, but it still doesn't run. is that only due to the program interpreter thing? (it's /lib64/ld-linux-x86-64.so.2 in the binary). if that's all, couldn't something be trivially patched to make it run? <attila_lendvai>ok, this works: ~/.guix-profile/lib/ld-linux-x86-64.so.2 geth version <montxero>Say I make an environment like so `guix environment --ad-hoc python python-flask`. Is it possible to reuse the environment or do I have to recreate it each time. More generally, is it possible to make environments akin to python virtual environments which are not limited to single session use? <civodul>montxero: hi! note that "guix environment" will be quick if you rerun it later with the same arguments, because the environment is still in store <civodul>you might prefer to use separate, persistent profiles <civodul>via "guix package -p /path/to/profile" <leoprikler>btw does anyone else get weird guix autocompletions with zsh on packages? <leoprikler>e.g. guix build 0ad\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ *civodul gets nice completions with Bash :-) <leoprikler>tbf I could probably get by with just bash, realistically speaking, but I'm too lazy to make the switch back and we shouldn't shoo away zsh users :P <Iacob>make: stat:Makefile: sterror: unknown error <Iacob>make: *** No rule to make target `bzip2'. Stop. <Iacob>I found that it cannot do ``guix pull'' <bricewge>I updates the zsh completion recently, when I tested it there wasn't such strange completion <leoprikler>it's not that recent and has been that for a while <bricewge>The update didn't touched the package list so I'm not sure it would help you in this case <bricewge>Taking a broader view, I think the ZSH completion should be revamp as it's mostly a list of strings describing the options. <bricewge>There is no easy way to maintain those strings in sync with guix proper and bash completion do away them <Iacob>rewrite them with scheme syntax? <Iacob>I found there's already guile in a newly installed debian os <Iacob>don't know who put it in the dependency list <bricewge>Iacob: No, I meant getting the options from the guix command programmatically instead of hard copying thoses string in the completion script <bricewge>I never wrote shell completion so I won't give it a shot personally I think <Iacob>It seems it's really possible to write shell completion in another scripting language <Iacob>If do this in scheme, some function wrapper might be needed <roptat>I pushed the new translations yesterday and this morning to guix and the website <roptat>hopefully, we will soon see the new Traditional Chinese and Turkish translations of the website <roptat>there is a new Italian translation for some package descriptions, and updates to other languages <Iacob>the server bandwidth does not fit for the quantity of the software and document <Iacob>HTTP download failed: 403 ("rate limit exceeded") <sneek>efraim was in #guix 16 minutes and 15 seconds ago, saying: sneek: seen mbakke. <efraim>mbakke: did you get an email from Nishant Sharma about a week ago? <mbakke>efraim: I did, thanks for the reminder! I have replied now. *apteryx optimized the rust bootstrap a bit more by only building stage 1 for the intermediate rusts <apteryx>hopefully we can build the rust bootstrap on a x200 in a less than a day in the next release ;-) <leoprikler>raghavgururajan: instead of patching the tests to do nothing, try to disable those test setups <leoprikler>the default test setup according to upstream is wayland <leoprikler>so you should `meson test --setup=x11` on command line inside the check phase <leoprikler>maybe we should add support for --setup in meson-build-system <raghavgururajan>We could replace the string "wayland_enabled" to "wayland_disabled"? <rekahsoft>Today I noticed that the emacs-org-roam package is not working as expected. Namely, they refactored some of its functionality into another directory (called "extensions"), but the .el files in this directory are not compiled or even included within the package. How would one include the "extensions" directory when using emacs-build-system? <rekahsoft>I'm aware of the #:include option, and looking at the source, this will likely do what I want. <abrenon>are there additional things to do when running an ocaml toplevel to find installed packages ? <abrenon>I'm trying to package a lib and I wanted to enter a toplevel to look around and check if everything seemed to be there but I can't seem to load .cma using the #load directive <abrenon>I've found examples online that mention topfind, is this linked to ocaml-findlib ? <abrenon>(I used to use ocaml a great deal about 7~8 years ago but it's been a while and I never used it on guix before so I guess I'm kinda confused between what I remember, what I think I remember and the intrinsic complexity brought about by guix) <abrenon>aren't you very knowledgeable regarding ocaml among other things ? <roptat>abrenon, yes topfind is provided by ocaml-findlib <roptat>you probably want to have an environment with ocaml and the dependencies, but then I don't know how the toplevel works ^^' <maximed>Hello! I'm trying to update curl@7.77 to curl@7.78. It builds. Does anyone know a good dependent to test? <leoprikler>rekahsoft: I think the correct thing would be to make an extra package named "emacs-org-roam-extensions" which has org-roam as input and chdirs into extensions before its build <leoprikler>a different approach would be to copy the extensions dir into the working directory <leoprikler>both assuming that upstream takes "extensions" as a potential load path root <leoprikler>raghavgururajan: respect instead of honor, also what about IM_MODULE_FILE? <leoprikler>the comment in the check phase sounds a bit weird. Perhaps "Run tests using the x11 setup instead of the default wayland." <abrenon>but I entered an environment with guix environment --ad-hoc rlwrap ocaml ocaml-findlib ocaml-libcaml-grew <abrenon>and the directive : #use "topfind";; returns an error ("Cannot find file topfind") <abrenon>I checked my $OCAMLPATH and everything seem to be in there so I'm a bit confused as to what is expected by the toplevel <yoctocell>abrenon: hi! I probably wouldn't use the word "very", but I do have some experience with ocaml and guix :-) <sneek>Welcome back yoctocell, you have 1 message! <sneek>yoctocell, iskarian says: but do we want to make having 'git' and its dependencies installed a requirement for 'refresh'? hmm... maybe we can add it to guile-git if it's already in libgit2? I vaguely recall seeing a ls-remote example in libgit2 <yoctocell>sneek: later tell iskarian: I haven't looked into ls-remote from libgit2, will take a look :-) <yoctocell>sneek: later tell iskarian: I am not sure if depending on `git' being in PATH would be such a big problem; it is only a requirement if one tries to update something hosted on a Git repo, and I would think that most people who run `guix refresh' run it from their local Guix checkout, meaning that they already have `git' in their PATH. <raghavgururajan>leoprikler: I'll get back to you on that. Btw, do you know how to remove #:argument under substitute-keyword-arguments? <maximed>raghavgururajan: strip-keyword-arguments <maximed>or, often equivalent, set it to the default value <iskarian>hmmmm. yoctocell, do you think that the same should apply for `guix download'? (regarding #50274) Of course, in builders, `git' is used. I wonder if we could (or would want to?) eventually get away from that with a well-developed guile git? <sneek>Welcome back iskarian, you have 2 messages! <sneek>iskarian, yoctocell says: I haven't looked into ls-remote from libgit2, will take a look :-) <sneek>iskarian, yoctocell says: I am not sure if depending on `git' being in PATH would be such a big problem; it is only a requirement if one tries to update something hosted on a Git repo, and I would think that most people who run `guix refresh' run it from their local Guix checkout, meaning that they already have `git' in their PATH. <iskarian>Of course, svn, hg, and so on would still use their binaries <raghavgururajan>maximed: Can it be used along with substitute-keyword-arguments block? <maximed>(substitute-keyword-arguments (strip-keyword-arguments ...) ...) <abrenon>yoctocell: so, yeah I was asking my way around the toplevel, and more specifically topfind and the #use directive <abrenon>I'm trying to package a lib and I managed to produce an environment that seem to contain it and I wanted to enter a toplevel with that and load it just to make sure everything looked alright <maximed>The (package-arguments gtkmm) needs to be moved inside the strip-keyword-arguments I think <maximed>As it is now, I expect you'll get syntax error <abrenon>but, despite the library showing up under the /gnu/store/… path returned for my environment, mentioned in $OCAMLPATH, I could never managed to load the .cma file with #use <maximed>maybe swap the '(#:meson) and (package-arguments gtkmm) <abrenon>and adding ocaml-findlib to the environment, I couldn't even #use "topfind" either, so I wanted to know how one was supposed to go about this use case <abrenon>how would you load a .cma inside an environment for test purposes ? <maximed>See (guix build-system ...) for some examples (at least on core-updates, possibly on master too) <leoprikler>you could simply reset the argument to some default value *raghavgururajan looks for hidden meson flags regarding im-modules <voroskoi[m]>guix dowload page is a bit confusing, it says guix can be installed on aarch64, but there is not iso for it <civodul>voroskoi[m]: hi! there's a download link for Guix proper, but not the ISO, which is for Guix System <muradm>is there any plan to merge master to core-updates-frozen? <civodul>voroskoi[m]: lack of an ISO for aarch64 is in part due to a lack of standardization of the boot process on aarch64 <civodul>muradm: sure, and the other way around, i hope! <leoprikler>I think we're currently still cleaning up some stuffs, e.g. the java thig <iskarian>Is there a way to set #:parallel-build? from the command line? <muradm>leoprikler: what is the issue with java? <voroskoi[m]>does the proper support musl-based distros, alpine for example? <civodul>iskarian: you can pass --cores=1, though that also applies to parallel builds <iskarian>Ah, yeah, I suppose that would yield the same result. Hmm... still getting "runtime: failed to create new OS thread (have 2 already; errno=22)" building Go 1.16 for aarch64, even with --cores=1 <muradm>civodul: we want ant-bootstrap from core-updates-frozen to compile with the remaining java stuff, right? <iskarian>(regarding my last message: turns out it's a QEMU issue) <roptat>muradm, right now, ant-bootstrap doesn't build on core-updates-frozen, and messing with classpath-bootstrap (a dependency of ant-bootstrap) seem to solve at least that issue <roptat>but we haven't really found the reason for the issue, none of the proposed solutions are very satisfying <roptat>mh, this is an issue: `(define-diagnostic info (G_ "") %info-color)` <roptat>not sure what's the intent, but we can't translate an empty string ***wonko is now known as w7
***w7 is now known as wonko
<maximed>roptat: There is some macroology in that file to not actually call 'gettext' on the empty string <roptat>but gettext still complains because it finds that empty string <maximed>Maybe a comment ";; (G_ "") is fine here because: ..." is in order <roptat>I don't understand how this gets translated, from reading other comments it seems it gets transformed to "~a"? <roptat>same for "warning: " -> "warning: ~a"? <maximed>roptat: (use-modules (guix i18n) (guix diagnostics)) (info (G_ "hi")) doesn't give me any errors <maximed>(it doesn't give any non-error output either) <maximed>The (G_ "") should be replaced with "" perhaps <roptat>I mean, I get `msgid "warning: "` in the pot file <roptat>with a comment that `"~a" is a placeholder for that phrase.` <maximed>roptat: can you reproduce with (use-modules (guix i18n) (guix diagnostics)) (info (G_ "hi~%"))? <roptat>oh I think I understand, the ~a is misleading, the message is actually printed in two steps <maximed>Or are you calling (G_ "") is isolation? <roptat>no it's fine, it's working as expected <roptat>though, guix repl prints the messages in English <iskarian>can someone with a native armhf/aarch64 system confirm that go@1.4-bootstrap-20171003 builds natively? (If it seems to build fine that's enough; you don't need to let the tests run) <iskarian>I'm getting failures on "cmd/5c" running under QEMU so if it gets past that it's probably fine <roptat>mh, I have a substitute for that version :p <roptat>that's an older guix, from june 17 <roptat>if you need something more recent, you'll have to come back tomorrow :p <iskarian>I suspect it's cross-compiled? Or does CI not do that? <roptat>oh, yes it might be cross-compiled <roptat>cross-compilation gives you a different store item <iskarian>ah, okay, nevermind then, that's confirmation enough :) <roptat>but it's built from an aarch64 system <roptat>(the armhf substitute was built with qemu though) <roptat>but probably from an aarch64 system <iskarian>I get the same issue with --system=armhf-linux <roptat>we had issues with qemu, so we had to stop building substitutes for armhf <iskarian>Yeah, it seems like all of Go does not agree with being build with QEMU <iskarian>So all of the aarch64 substitutes are native builds now? *roptat is now pulling all his systems <roptat>maybe I should start using guix deploy, could be fun <dissoc`>speaking of arm builds, is there a decent guix package web browser that succesfully builds? <roptat>dunno, I use arm only on a server <dissoc`>surf built but it crashes too frequently. i tried building icecat and ungoogled-chromium but they failed <dissoc`>i made a pinephone image. but go good web browser builds. i'll have to debug it when i have tome <yoctocell>iskarian: re remote-ls in libgit2, looks like there is a remote-ls procedure in guile-git, but I have no idea how to use it... <ssouth>strace 5.13 from core-updates-frozen is failing to build for me on AArch64. Anyone else notice this? <ssouth>apteryx: Yes. The readlinkat test is failing, I'm guessing for the same reason mentioned in a comment in the package definition. <ssouth>Looks like there is an additional call being made the test harness isn't expecting. <apteryx>OK. It's probably a real problem; could you please open a ticket about it? <yoctocell>iskarian: I figured it out, thanks for the pointer! <yoctocell>But I have to first clone the repo and then use `remote-lookup' to get the `remote' object <iskarian>Yeah, perhaps look in (guix git) for how we do that stuff? <iskarian>yoctocell, I recall seeing that it will also return deleted heads, so once you get it working you might need to filter those out ***iyzsong- is now known as iyzsong
<civodul>roptat: yay for the new translations! <ssouth>apteryx: You're welcome. I see Linux doesn't provide the "readlink" syscall on AArch64, only "readlinkat", so I bet it's the exact same issue as with the "readlink" test elsewhere. <jave>but somehow the channel shows up as "flat" on guix pull, but i cant find any packages from the channel when i do guix search <roptat>civodul, oh, I didn't notice, thanks <geex3>check out 'git.io/vpn' script for creating a openvpn server on a fresh vps easily. it spits out .conf files (.ovpn files) -- to use this sort of config on other os typically we would just move it to /etc/openvpn/, how can i do this in operating-system definition? (with or without network-manager, preferably with) -- have looked but no real results popped up <geex3>need to split out cert,ca,key into /etc/openvpn/client.key etc? <civodul>roptat: the footer in the zh-* translations has literal markup too <geex3>regarding the openvpn-config, here is example .conf file that it produces (with some config.scm i added at the end of the pastebin), https://pastebin.com/raw/azmpRi7f -- how to use a file like this and keep the contents relatively private? <roptat>jave, what's the output of "type guix"? <iskarian>yoctocell, congrats! I think that was actually the biggest blocker for a functional generic-git updater <geex3>ideally i would just copy the .conf to /etc/openvpn/ and the openvpn-client-service should pick it up, maybe by name... maybe thats what the ccd dir is for? <mjw>hmmm, trying to build gcc from git I get: <mjw>The directory that should contain system headers does not exist: <jave>guix is hashed (/bin/guix) <mjw>gcc.gnu.org git that is. And obviously /usr/include doesn't exist <roptat>it should be in ~/.config/guix/current/bin instead <mjw>Does gcc need patches to build on guix? <roptat>make sure it's first in your $PATH and run "hash guix" (no output) on all your open terminals to make sure your shell finds it at the right location *dstolfa pulls and tests offlineimap3 <roptat>mjw, I don't think you'll need patches, but you might be missing dependencies or environment variables to have your current gcc look at the right header locations <yoctocell>iskarian: yes, hopefully we can get you "Add upstream updater for git-fetch origins" patch merged soon! <mjw>CPLUS_INCLUDE_PATH=/home/mark/.guix-profile/include/c++:/home/mark/.guix-profile/include <mjw>C_INCLUDE_PATH=/home/mark/.guix-profile/include <iskarian>Heh, the patch needs a lot of work, and I think I'd rather wait for #50274 and possibly #50286 to be merged first, but yes! <jave>thanks roptat! So now in .bashrc i get export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale" <jave>export GUIX_PROFILE="/home/joakim/.guix-profile" <jave>. "$GUIX_PROFILE/etc/profile" <jave>export PATH="~/.config/guix/current/bin":$PATH <civodul>mjw: howdy! it might be that you can build it with: guix build -e '(@@ (gnu packages gcc) gcc)' --with-git-url=gcc=https://... <mjw>odd, it really seems gcc has /usr/include hardcoded when running the fixincl <mjw>civodul, ehm, ok, but does that mean I need to commit my hacks to my local git repo first? <mjw>not that I don't want to try using guix build, but is that really how people hack on gcc? <civodul>otherwise you can check the configure flags and variables used in (gnu packages gcc) <civodul>no, to have on GCC, i'd do "guix environment -e '(@ (gnu packages gcc) gcc)'" and build "the normal way" <civodul>mostly you need the right set of flags <mjw>ok, lets try guix environment <mjw>nope, same issue. It really seems to want to run fixinc on /usr/include and doesn't like that dir is epty <civodul>mjw: did you pass --with-native-system-header-dir=... ? <mjw>civodul, no still reading gcc.scm :) <mjw>also I am pretty bad at interpreting scheme, so trying to figure out what that will expand to <civodul>mjw: incidentally, roptat & i have been fiddling with code of yours (?) lately, in Classpath <mjw>OK, we are getting somewhere... <mjw>The directory that should contain system headers does not exist: <mjw> /gnu/store/94j6q1a78k7pbddidx6vjqypfysnip9h-profile/include:/home/mark/.guix-profile/include <the_tubular>I'm not sure I understand, which package should be in config.scm and manifest.scm ? For a single user VM <civodul>however, i'd recommend doing "guix environment -CP", so that the directory is always $HOME/.guix-profile/include <civodul>(otherwise the hash could change and you have to rebuild) <mjw>civodul, Do you need any patches? The project is very dormant. But if we can help the bootstrap become easier we can certainly do a release with some fixes. <civodul>part of it seems to be surprising miscompilation <civodul>but i wonder if there could be ABI incompatibilities or something <mjw>It disappears with CFLAGS=-O0 ? urgh <muradm>civodul, roptat: do you want patch for 49990 java issue? ) <muradm>abort: error: Temporary failure in name resolution <mjw>civodul, I don't understand why, but I think your patch is correct. jboolean should be an unsigned 8bit type <roptat>not related to the package definition <mjw>no, I am wrong, it was a unsigned 8bit datatype, you turn it into a signed int <mjw>that should not work! :) <roptat>I think civodul was confused because there is another issue in isDirectory that happens before the one in isfile <muradm>i faced similar problems with other things <muradm>currently it is getting compiled with gcc-10 i think <mjw>wow, it has been such a long time I hacked on this code <muradm>i would suggest to compile ancient things with ancient gcc <muradm>this patch just tricks gcc, nothing else <muradm>i also tested some other susspicious methods from VMFile like isDirectory, exists, getCanonicalPath, etc. <muradm>all seems good, and no need for memory leak :) <roptat>I mean, I don't understand what your patch is trying to achieve <roptat>I see it's just a more complex way to do the same thing, but I don't understand why we need to do that <muradm>(*env)->ReleaseStringUTFChars(...) does lot's of things i gets, value of result and entryType remains in registers <muradm>and gets overwritten or something <muradm>so i make a variable, and calculate final result before that heavy call <muradm>also trick compiler not to do optimizations for oneliner <roptat>ok, so maybe we can get away with a mix between civodul's patch (computing the result as one line before ReleaseString), and your changes to cpio.c? it would be cleaner if that works? <muradm>otherwise value of entryType passed as pointer to cpio_checkType also gets evaluated lazily or something <muradm>i didn't see anything wrong with cpio.c, i would not touch that <muradm>issue is with what (*env)->ReleaseStringUTFChars does and how gcc compiles it <roptat>but changing isDirectory the same way we changed isFile doesn't help ./ <mjw>which jvm are we using? <muradm>isDirectory working as it is now <roptat>I thought maybe your changes to cpio were the ones having an effect on isDirectory? <muradm>seems like again gcc & friends issue <roptat>muradm, so I don't understand which patch do you apply to classpath-bootstrap' <muradm>roptat: if you apply my patch which changes Java_java_io_VMFile_isFile is enough <roptat>yes, but you still need to leak in isDirectory, no? <roptat>what about the package definition? did you change anything? <muradm>for me it compiles and works with and without it, i looked at 36685 and didn't understand the problem and solution <muradm>since it worked any way, i left it untouched <muradm>let me see again if that substitute removable <roptat>I mean, the package compiles, the issue is in ant-bootstrap, later <civodul>mjw: this is all with an ancient jamvm <roptat>muradm, with your patch, ant-bootstrap still fails with "Could not load the version information" <civodul>Beer: argh, thanks for the pointer! if that's fine with you, please raise it on guix-devel@gnu.org so we can discuss what to do next <roptat>there's a similar discussion going on in LFS <civodul>ah good, maybe we can wait for them (you? :-)) then <roptat>I haven't followed the discussion, but I can read it and report their plans ***ec_ is now known as ec
<muradm>roptat: i will commit localy now to make clean patch <muradm>i supposed i messed with copy paste <muradm>for me, my changes build until icedtea <roptat>they do if I keep the substitute, but not if i remove it <roptat>and if we keep the substitute, then we could keep civodul's patch, it's shorter <montxero>civodul: Thanks for pointing me to profiles <muradm>yes substitute should stay i think <Beer>civodul: It's a friendly notice because that matter has just been raised o nthe Devuan side I come from <Beer>We were wondering what solution you'd had come up with, since we're on the same boat. It turns out your mailing lsits were mute about it, so I decided to come over here :D <muradm>roptat: great then, i tried that originally i think, may be messed with testing :) <civodul>Beer: heheh, you did well, thanks! IIUC, Gentoo is now using stock udev, which means it can be compiled without the rest of systemd? <muradm>roptat: you know solution at least, then i don't send mine :) <dstolfa>maximed: i don't think CDDL is an issue unless you distribute the resulting binary? <dstolfa>that is to say, unless you provide a linux kernel with ZFS compiled in <dstolfa>IIRC it was something along the lines of the GPL and CDDL binary clause being a bit in the grey area <maximed>dstolfa: we do kind of distribute the resulting binary ... only lazily? <dstolfa>the user has to compile it, there's no substitute <maximed>We provide automated build recipes, which seems functionally equivalent to distributing to me <dstolfa>that's not really how licenses work though <dstolfa>a build recipe isn't the same as distributing a binary <dstolfa>otherwise most scripts would be in some kind of violation <maximed>in particular, ‘Is the Analysis Different With Source-Only Distribution’ <dstolfa>maximed: so how is a build recipe that debian has different from the one guix has ***Xenguy is now known as Xenguy_
<maximed>And (the linux variant of) OpenZFS is a modifification of Linux? <dstolfa>yes, so distributing a zfs.ko is questionable. however, a build recipe that is distributed by guix is no different from running make manually <dstolfa>the user should be aware that they can't redistribute the resulting kernel to others without some grey area, so a warning might be sensible <dstolfa>but it's only really relevant if you redistribute binaries <maximed>dstolfa: I don't see much of a difference between a build recipe in Guix and a build recipe in Debian <muradm>roptat: i tried your patch, it didn't work for me, i suppose these fixes are not consistent across CPUs may be <roptat>did you put the substitute back? <dstolfa>maximed: would it make sense for there to be a link to the FSF article when someone does `guix package -i zfs`? <maximed>running a build recipe and running make manually doesn't seem very different (ignoring convenience) <dstolfa>e.g. "ZFS is CDDL licensed and redistributing the resulting kernel module is in a legal grey area. See <insert link> for more details" <maximed>A user, deciding by theirself, ‘let's take Sun's OpenZFS, modify it to work with Linux, use it, and keep it to myself’ --> seems perfectly fine <Beer>roptat: Thx for the link. I shared it in our meeting notes. If you come up with anything on your side, we would be glad to know about it: we got our channels over here too (o: <Beer>(I'm no dev; merely relaying concerns/info) <dstolfa>yeah, i think we'd just really want to warn regarding redistribution, maybe link to the FSF article + remind users of one of the 4 freedoms potentially being violated when it comes to the binaries?