<jsoo>i finally read most of eelco dolstra's thesis. i found it very helpful <jsoo>i'm curious how many other people using guix used nix before? <palpares>should be equal to people who used nix and use guix after. hope this help <sirgazil>so far, rofi works better than dmenu. I didn't notice any slowness. <Veera>Does building guix packages requires knowledge of Guile/Scheme? <nothingmuch>Veera: i have only very basic skills and i managed to write them a few for personal use without much trouble <nothingmuch>the main challenge for me was learning the guix specific details, like different build phases <Veera>I know Python/Perl/Lua/Bash; will it be easy then <nothingmuch>i think so, i scheme is very clean/regular in my experience, and felt pretty familiar to me knowing perl & python, just far fewer details to remember <nothingmuch>that tutorial is excellent, it's rich in details and introduces just enough complex stuff that i can now understand most package definitions by just reading them <Veera>Does guix uses lamda expressions in pkgs <nothingmuch>for example to add a custom phase you need to supply a function, which afaict is always written as a lambda <Veera>Are lamda expressions diificult to grasp/learn/use <nothingmuch>there's an old LISP video course from the 80s i watched years ago which was very helpful for understanding these concepts, Structure and Interpretation of Computer Programs <nothingmuch>there's also a free textbook that goes along with it, but i didn't read it myself <nothingmuch>i learned to program from reading perldoc, and that course really helped me, it was my first exposure to a slightly more academic perspective, and i still reccomend it <nothingmuch>but caveat, it's Scheme is not LISP, even though it's very similar <Veera>Yesterday in mail I got to know of this book <Veera>It said the book is available as a info doc available in GuixSD <Veera>mail archive is available in guix-devel mailing list <nothingmuch>huh, i didn't know about it, but you're right: guix environment --ad-hoc sicp texinfo <nothingmuch>fwiw you don't really need that level of depth for just hacking <nothingmuch>i would still reccomend it, it's wonderfully insightful, but it deals more with abstract ideas like modularity/suppression of detail, how to think about compilers, domain specific languages, etc <nothingmuch>just writing packages in guix is pretty straightforward <Veera>oh that would be useful afterall <nothingmuch>and that tutorial i linked also introduces bare essentials of scheme <sirgazil>Veera: Don't worry about not being a CS graduate. You don't have to be one to learn how to use lambda expressions :) <Veera>sirgazil: that's good to know <sirgazil>Veera: So, did you installed Guix on your distro already? Or did you decided to install the Guix System? <Veera>sirgazil: Have downloaded the iso image. Today I am going to install it in VM. <Veera>sirgazil: Installation steps are less, simple and easy. <Blackbeard>Gooberpatrol66: was having the same problem as you @freenode_sirgazil:matrix.org <Blackbeard>defs.h:20:11: fatal error: SDL_mixer.h: No such file or directory <Blackbeard>guix-vits:let me try, I checked parabola definition and they use 1 thought <guix-vits>Blackbeard: possibly it worth to check the definitions for some games that require sdl-mixer ... <guix-vits>"SDL is required by ALL games and SDL_mixer is recommended for LGeneral, LBreakout2 and LTris." <guix-vits>Blackbeard: in games.scm, "The Emilia Pinball Project", (arguments ... ? <guix-vits>also: ("sdl-union" ,(sdl-union (list sdl sdl-image sdl-mixer))) maybe will work. <guix-vits>Blackbeard: use https, please in `(uri` (works). <g0d_shatter>hey all is there a document somewhere that gives a contributor a guide to the source? <g0d_shatter>Blackbeard: I guess like a developers documentation? <g0d_shatter>I'm just sifting through the source and wanting basically a source map, if one exists. that was what I was trying to get at <g0d_shatter>its not a super big deal, I'm sure at some point I can knock up a script that shows me relations among the various modules <Blackbeard>I thought you were asking a simpler question :) like how to contribute ***apteryx is now known as Guest95484
***apteryx_ is now known as apteryx
<Blackbeard>I've been working on setting my development environment and everything <Blackbeard>guix-vits: oh yes you are right, I need to compile them for other architectures :/ <NieDzejkob>sneek: later tell Veera: Don't worry about lambda expressions. It's a simple concept with a scary sounding name - a lambda is just a function that doesn't have a name <guix-vits>NieDzejkob: s|function|procedure| :trollface: <NieDzejkob>guix-vits: these terms are commonly used interchangeably, although yes, a lambda in scheme may have side-effects <guix-vits>NieDzejkob: O_O` -- thanks, i didn't thought there is a difference, btw. <janneke>almost done with reduced set of %base-packages for the Hurd <janneke>just found that glibc needs another patch...working around and postponing that <janneke>hmm, man-db and sudo have a pretty big closure <civodul>it's not clear to me why man-db references util-linux, bzip2, and xz <efraim>The Hurd is actually implemented entirely in glibc, with gnumach being the actual microkernel part. The Hurd is 'just' the management around all the bits <janneke>civodul: and cmake, python, tcl, tk, libx*, nghttp2... <efraim>sneek: later tell guix-vits musl-lib won't work for the Hurd because [13:10] <000000efraim> The Hurd is actually implemented entirely in glibc, with gnumach being the actual microkernel part. The Hurd is 'just' the management around all the bits <janneke>now that i almost have %base-packages, i'll be going back to removing the full qemu dependency from the operating-system build <janneke>somehow, despite someone's hard efforts to use qemu-minimal (or even qemu-tiny), there are still two full qemu dependencies too <janneke>efraim: glibc does implement a lot of posixy'ness but there's also stuff implemented in `hurd' itself? <civodul>janneke: oh, where do you see that? "guix size man-db" on current master doesn't have all this <civodul>or were you referring to the build dependencies? <janneke>civodul: yes, that's probably build dependencies (thanks for asking, this helps my thinking a lot) <sneek>guix-vits, you have 1 message. <sneek>guix-vits, efraim says: musl-lib won't work for the Hurd because [13:10] <000000efraim> The Hurd is actually implemented entirely in glibc, with gnumach being the actual microkernel part. The Hurd is 'just' the management around all the bits <efraim>janneke: Just saw your message. I'm not sure, but I was told something along the lines that everything from the herd is implemented in glibc so it can't be switched out. Not too sure about the internals though <janneke>efraim: ah yes, in a way i think that's right <janneke>in any case, glibc is an essential part of the Hurd <janneke>i'm pretty sure that glibc and mes lib c are the only two c libraries that support exit,read or write on the Hurd <guix-vits>Fedora-offtopic, in case someone cares: why `cat` may return `read-error` "Invalid argument"? <janneke>civodul: ah, gnu/system/shadow's default-skeletons copies from guile-wm <dftxbs3e>so python-pyopenssl package's tests are failing now because we're in 2020 - and ci.guix.gnu.org has it as a substitute because it built it some time ago when the date didnt make the tests fail <dftxbs3e>can't GNU Guix set the current date to something always the same during tests? I realize it's not possible to get always the same time data considering Linux isnt a real time system and scheduling will be non-deterministic <nckx>guix-vits: Indeed. That error is from the kernel. ‘Invalid argument’ means ‘hardware/feature/reading/… not supported’ in kernel land. <rekado>dftxbs3e: the tests should be fixed. It’s weird to have tests that depend on ${current-year} <dftxbs3e>rekado, did you just commit to GNU Guix? Well for TLS/SSL certificate tests, it's not surprising to me. <dftxbs3e>They should generate the dates and certificates they test with on the fly so that they always use some current date. <dftxbs3e>I'll have so many fixes to submit upstream... some powerpc64-linux related, some not. <efraim>Where's your tree? I might be bored or motivated to cherrypick some of them *efraim is on my phone, will look later <rekado>I haven’t pushed anything on pyopenssl <dftxbs3e>Ah ok. I thought you said you just fixed it with 'The tests should be fixed' <rekado>‘should be fixed’ does not mean ‘I fixed it’ to me :) <dftxbs3e>rekado, ah.. well I usually say that when I've fixed something but have yet to test the fixes extensively <rekado>I meant: ‘someone™ should fix this’. <rekado>I see now how this could be misunderstood. <dftxbs3e>mbakke, ahh.. cool. `faketime` interesting. Thanks. <rekado>sys2: having 0 byte files sounds like file system corruption. It’s unrelated to using substitutes or not. <sys2>rekado: yeah the thread made it seem like running two package commands at once... which I may have done at some point. Is there a way to re-initilize it, or get the profile back I had before? <rekado>sys2: running two commands that modify the same profile is no longer possible with recent versions of Guix. <sys2>rekado: is there a way to recover or reset that profile? I'll be more careful going forward... I just assumed guix package would complain if I was doing something that wasn't allowed <rekado>it *does* complain. When you try to modify the profile from two separate processes it will abort the later. <rekado>you can build a new profile e.g. by using a manifest file. <rekado>with guix package -m my-manifest.scm <sys2>ohh, that defaults to ~/.guix-profile/ when you don't specify -p? <sys2>if it complains, how is it possible to run two commands? is it just a warning? or allowed in earlier guix versions but not recent versions? <sys2>so it's okay to delete ~/.guix-profile/* and run guix package again? <guix-vits>sys2: create password for root; in case of something wierd you'll able to login and repair. Then lock root again. <sys2>guix-vits: I have a password for root.. should I not normally? <rekado>add ‘,repair’ to fix the problems it reports <rekado>it should not report anything, ideally <rekado>sys2: yes, guix gc will remove the profiles when nothing points to them any more. <sys2>sorry to ask so many questions.. but to clarify the above one about profiles... all I have to do is delete the symlink ~/.guix-profile (not even any of its contents?), and guix gc will know it's not used anymore? feels wierd to not have to do anything else <rekado>when you delete it Guix will assume that you have no default profile. <rekado>it will then build a new one and link ~/.guix-profile to it. <sys2>crazy. I ended up moving my desktop.scm manifest to it instead (and getting rid of that profile) <sys2>I had another profile, but I didn't know you could use a manifest on the default profile. makes sense.. I was just using that more as a testing grounds (trying out apps), then adding them to another manifest/profile after I decided to stick with them <sneek>Welcome back Blackbeard, you have 1 message. <sneek>Blackbeard, guix-vits says: Please use a doubled spacing after '.' in `(description`; seems that all packages has this style in games.scm: ". ". <rekado>‘guix lint’ will also complain when it sees a single space following a period. <efraim>There's an existing rakudo build system. I don't know anyone is really looking after it too much though <Blackbeard>I was just writing my second package and it was late <Blackbeard>I just need to test them in different architectures <Blackbeard>But at least they work on my computer and I am happy :) <lafrenierejm>efraim: I thought rakudo was perl6? raco is Racket's package manager. <efraim>Oh, wow. I got that one way wrong <lafrenierejm>efraim: No worries. I posed the question to the help-guix mailing list just now; maybe someone there will know. *sirgazil found the rofi slowness now. <rekado>I wonder if rofi might be slow due to Guix search paths. <sirgazil>rekado: but it is slow to start sometimes, not always. Autocomplete works ok so far (contrary to using autocomplete with GNOME's Alt+F2) <thomassgn>what does this mean '(let ((source (assoc-ref %build-inputs "source")) ....' do I need this to reference the source in a package? <thomassgn>to clarify, I'm writing a trivial-build, I just want to keep some files in the store and reference it as a package, I see I get almost what I want from making source a file-union, but I'm struggling getting it all together... So this is for copy-file as the build procedure for trivial-build... <thomassgn>Blackbeard: I didn't yet. Will look through it now. Thanks <thomassgn>Blackbeard: it's not what I need. I'll see if I understand the docs for assoc-ref and what's in %build-inputs. If you know I'd love to hear your take on it. <nckx>thomassgn: (assoc-ref alist key) is just a procedure that fetches the value from an alist (= list of key-value pairs). Equivalent to e.g. ${build_inputs["source"]} in bash. Does that clarify things? It will return the /gnu/store path to the source, which you can then extract or copy depending on what kind of thing it is. <nckx>git-fetch results in a directory, url-fetch in a file. <nckx>Does that answer your question? Wasn't clear to me exactly what it was 🙂 <nckx>You only need this for trivial-build-system packages (and maybe the new copy-build-system too). The others helpfully extract or copy the source into the current build directory. <sirgazil>The "python-sphinx-autodoc-typehints" package comes from a custom Guix channel of mine. If I comment it out, the manifest is evaluated correctly. <sirgazil>I can build and install the "python-sphinx-autodoc-typehints" package without problems. <efraim>You might need 'guix package -L /path/to/channel -m manifest' <sirgazil>efraim: But I have the custom channel in ".config/guix/channels.scm" and already pulled. <mroh>sirgazil: try to put your packages in the module path that you can include with -L or GUILE_LOAD_PATH. for a nice example, see https://gitlab.com/alezost-config/guix (I learned (and still learn) so much from him...) <sirgazil>mroh: The package that makes the manifest fail to evaluate is already defined in a public Guix channel and that channel is already in my channels.scm file. I already pulled and can build and install the package. <sirgazil>mroh: I shouldn't need to use -L if I understand things correctly. <sirgazil>I use -L when I'm testing packages locally. <NieDzejkob>oh ffs. Rust 1.39 shipped with a Cargo.lock in a different format, which made the regex for patch-cargo-checksums stop matching <dftxbs3e>I guess next time to save some trouble one can look at the changelog <NieDzejkob>I don't think this would've been caught by the changelog <NieDzejkob>There's some mention of a /better/ manifest format in Rust 1.41 <dftxbs3e>NieDzejkob, well they've talked about the Cargo.lock format change <NieDzejkob>but if that's the cause, it would violate causality <NieDzejkob>the whole idea of the Cargo.lock format mattering for the build took me quite a while to grasp too <NieDzejkob>actually, I'mma write a big-ass comment while the compiler is... compiling <thomassgn>nckx: Hey, awesome. That's what I needed. Thank you. I found my way around it with that input :) <dftxbs3e>how can one get support for all emojis with say; font-google-noto? <dftxbs3e>I installed it but it doesnt work in IceCat for example *civodul updates guile-next on master <civodul>mbakke: so if everything goes well, we can switch to guile-next afterwards on core-updates <civodul>if things don't go so well, we can switch to 2.2.7 on core-updates <NieDzejkob>Hmm, I hope I can get some Rust upgrades before the core-updates merge <civodul>dftxbs3e: this is for both 2.2 and 3.0, right? <efraim>I ran into the same problem for 2.2.6, didn't try 3.0 <efraim>If I had to guess it was an endianness problem <NieDzejkob>Blackbeard: yeah, in your case you want two separate commits <Blackbeard>but I will need to check with the other architectures, lint and size <NieDzejkob>civodul: ouch, and we don't even get a core file, do we? <roptat>I think I have a plan for the maven build system bootstrap :) <roptat>building a maven-bootstrap package as quickly as possible, ignoring tests and removing features that are not needed seem to be feasible. I'll use my install-from-pom procedure to install maven and its dependencies in a fake maven repository <roptat>then using that maven-bootstrap, I should be able to build everything again, using maven when necessary, including test dependencies, until maven-bootstrap rebuilds maven <roptat>I'm trying to rebuild the dependencies now. i've got an update for junit, I unbundled maven from jarjar, bndlib and libg from asm bootstrap, updated lang3 to 3.9, but I'm still very far from done <roptat>I suppose I can get maven-bootstrap (with its most common plugins) in a week or two <roptat>I'll have a huge patch series for core-updates :p <Blackbeard>how can i do this "guix build --system=armhf-linux --rounds=2 hello" <roptat>or did you mean, how to build for armhf on i686? <Blackbeard>roptat: oh no I just meant i686, I want to build to it too <Blackbeard>the manual mentions armhf-linux, aarch64-linux, mips64el-linux <civodul>roptat: i'm not sure i follow everything, but it looks like you have a nice plan for maven :-) <Blackbeard>the videos are really well done, informative and quick <roptat>civodul, yep, and I do have a maven build system, so it's only a matter of time before I have everything packaged <roptat>it shouldn't change anything for our current java packages either, so we can convert them to maven slowly afterwards too <roptat>I'll also do an update of the maven dependencies while I'm at it <sirgazil>Trying to build Django 3.0.4 I get this lint message: gnu/packages/admin.scm:1445:2: hostapd@2.9: probablemente vulnerable a CVE-2019-16275 <sirgazil>Also: gnu/packages/admin.scm:1912:2: ansible@2.8.5: probablemente vulnerable a CVE-2019-14856, CVE-2019-14864 <roptat>this is unrelated to django, but it means we should probably update these packages <sirgazil>What would be the right thing to do? Report a bug per package or a single bug report listing all of them? <sirgazil>And guix lint errors at some point because "Error downloading release information through the GitHub API". *sirgazil needs Django 3 in Guix to leave pip behind. <NieDzejkob>sirgazil: linting all packages in guix will trigger API rate-limits <sirgazil>NieDzejkob: I ran "guix lint my-django". Is there any way to avoid that problem? <sirgazil>Or wait, I didn't. I actually made a mistake running the lint command :)