IRC channel logs


back to list of logs

<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.
<nothingmuch>rekado_: ah, i see, thanks for the clarification
<sirgazil>nothingmuch: Maybe check this for examples on using "guix package" with manifests to create profiles for development.
<Gooberpatrol66>Blackbeard: yes i think so
<nothingmuch>sirgazil: thank you!
<Veera>Does building guix packages requires knowledge of Guile/Scheme?
<Veera>I am a new user.
<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>yeah, those crop up on occasion
<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
<Veera>I am no CS graduate
<nothingmuch>i think they are simpler than in perl/python
<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>then you can run `info sicp`
<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 :)
<sirgazil>nor Guile
<Veera>sirgazil: that's good to know
<Veera>hi again
<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> hey
<Blackbeard>Gooberpatrol66: was having the same problem as you
<Blackbeard>How did you solve it?
<guix-vits>Hi Guix.
<Blackbeard>guix-vits: \o/
<Blackbeard>I am having a problem building a program
<guix-vits>Blackbeard: Hi. What program it is?
<Blackbeard>defs.h:20:11: fatal error: SDL_mixer.h: No such file or directory
<Blackbeard> #include <SDL_mixer.h>
<Blackbeard>guix-v barrage, a game
<Blackbeard>I am including sdl-mixer
<Blackbeard>("sdl-mixer" ,sdl-mixer)
<guix-vits>Blackbeard: sdl2-* ?
<Blackbeard>guix-vits:let me try, I checked parabola definition and they use 1 thought
<Blackbeard>that's why I went with 1
<Blackbeard>no it doesn't work, it needs sdl1
<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: Did you included `"sdl" ,sdl`?
<Blackbeard>guix-vits: i did
<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.
<Blackbeard>guix-vits: nothing :(
<Blackbeard>this should not be happening
<guix-vits>Blackbeard: i'll read (seen this recently there), and try to build this, then. indeed: "should not be happening".
<guix-vits>cool, i even not need to set-up a repo...
<guix-vits>Blackbeard: use https, please in `(uri` (works).
<Blackbeard>guix-vits: oh thanks :)
<g0d_shatter>hey all is there a document somewhere that gives a contributor a guide to the source?
<Blackbeard>g0d_shatter: what do you mean?
<Blackbeard>like how to contribute?
<g0d_shatter>Blackbeard: I guess like a developers documentation?
<g0d_shatter>so, there's what several dozens of scm files
<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
<Blackbeard>ahhh I see
<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
<g0d_shatter>just wondering if one already existsd
<Blackbeard>g0d_shatter: it might but I don't know enough
<g0d_shatter>no worries, thanks for responding!
<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>guix-vits: still here?
<Blackbeard>seems like you had the right idea :)
<Blackbeard>guix-vits: it works!!!! :D :D
<Blackbeard>now I have two games to send as patches :D
<guix-vits>Blackbeard: good; what changes were maded?
<guix-vits>Blackbeard: cool, thanks.
<Blackbeard>guix-vits: I'll send the patches tomorrow :)
<Blackbeard>for barrage and widelands :)
<guix-vits>Blackbeard: "rigorous testing" :P
<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 :/
<Blackbeard>but anyway I am happy :)
<Blackbeard>I gotta go to sleep now
<guix-vits>btw, compiles and works!
<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
<sneek>Will do.
<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
<guix-vits>janneke: musl-lib isn't fit, by chance?
<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
<efraim>Ah they weren't even here
<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
<sneek>Got it.
<efraim>sneek: botsnack
<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?
<civodul>so you're building things natively?
<janneke>civodul: yes, that's probably build dependencies (thanks for asking, this helps my thinking a lot)
<janneke>civodul: yes, i'm building natively
<guix-vits>efraim: thanks.
<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
<NieDzejkob>Wooh, I got rust@1.38 to build
<guix-vits>Fedora-offtopic, in case someone cares: why `cat` may return `read-error` "Invalid argument"?
<janneke>guix-vits: are you asking for help?
<guix-vits>janneke: no, they:
<guix-vits>but... "Invalid argument"!?
<guix-vits>looks like this sort of error is returned by driver (
<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 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
<dftxbs3e>Linux's not a real time kernel *
<nckx>guix-vits: Indeed. That error is from the kernel. ‘Invalid argument’ means ‘hardware/feature/reading/… not supported’ in kernel land.
<guix-vits>nckx: thanks.
<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 used: - and added the patch to my tree.
<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
<dftxbs3e>efraim, - but I havent committed everything yet.
<dftxbs3e>I'll do so in a minute
<rekado>dftxbs3e: yes, I did. Why?
<dftxbs3e>rekado, just now or some time earlier?
*efraim is on my phone, will look later
<dftxbs3e>efraim, MGit on FDroid :-)
<dftxbs3e>It's very good.
<rekado>dftxbs3e: both
<dftxbs3e>rekado, okay, because I can't see anything about pyopenssl so I wondered - last one is:
<dftxbs3e>(which is the one that failed for me)
<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’.
<dftxbs3e>sorry then :-S
<rekado>I see now how this could be misunderstood.
<sys2>Hi Guix, I'm running into this issue: (0 bytes ~/.guix-profile/manifest). Is there a good workaround? The verify command also lists a bunch of packages. I'm not sure if that's because I'm not using substitutes or why
<mbakke>dftxbs3e: there is a fix for pyopenssl on the 'staging' branch:
<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>ok cool, thanks
<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
<guix-vits>sys2: at least you can try :)
<rekado>~/.guix-profile has no contents
<rekado>it’s a link to something 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)
<rekado>I don’t understand that.
<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
<Blackbeard>Hello :D
<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.
<lafrenierejm>Is there any WIP toward a build system for raco?
<efraim>There's an existing rakudo build system. I don't know anyone is really looking after it too much though
<Blackbeard>Ah yes I'll use guix lint then
<Blackbeard>I was just writing my second package and it was late
<Blackbeard>But it works :)
<Blackbeard>Now I have to packages to send
<Blackbeard>I just need to test them in different architectures
<Blackbeard>And format them correctly
<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
<efraim>No idea about raco
<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.
<Blackbeard>sirgazil: what was it?
<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)
<sirgazil>Blackbeard: ¿Qué cosa? :)
<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>not sure that made anything clearer... :)
<Blackbeard>thomassgn: have you read the cookbook
<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>I can't evaluate this manifest with geiser:
<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.
<sirgazil>But trying to create a Guix profile using that manifest, I get this error:
<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.
<efraim>Well there goes my great idea
<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 (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
<NieDzejkob>It took me most of the day to figure this out
<dftxbs3e>NieDzejkob, :-/
<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
<dftxbs3e>' a more git-friendly Cargo.lock'
<NieDzejkob>yeah, look at the version numbers
<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
<dftxbs3e>If that's of interest to anyone, this is currently a blocker for powerpc64-linux port upstreaming:
<mbakke>civodul: awesome :)
<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>2.0.14 wasn't a problem for me
<efraim>If I had to guess it was an endianness problem
<Blackbeard>Every package is a commit right?
<Blackbeard>Even if I have two games
<civodul> <- oops
<NieDzejkob>Blackbeard: yeah, in your case you want two separate commits
<NieDzejkob>git add -p might help you
<Blackbeard>ok :)
<Blackbeard>for now I am guix build widelands
<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?
<NieDzejkob>is it reproducible?
<Blackbeard>so it will be a while before I send the patches
<civodul>NieDzejkob: dunno, i just noticed
<roptat>hi guix!
<civodul>hi roptat!
<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"
<Blackbeard>for 32 bits
<Blackbeard>or i686
<roptat>replace armhf with i686
<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
<Blackbeard>but I wanted to add i686 :)
<roptat>then it's i686-linux ;)
<Blackbeard>wonderful :)
<Blackbeard>soon I'll send my patches :D
<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
<sirgazil>And some more.
<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?
<roptat>a bug per package I think
<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 :)