IRC channel logs
2024-11-17.log
back to list of logs
<ekaitz>divya: take a look to cbehave and how it uses open-file <divya>ekaitz: i was just looking at it, I didn't know you could do this, hah. <ekaitz>divya: phases are just guile code <divya>Right, we're using guile procedures to operate on files and other stuff. Pretty powerful. Let me see how I can use open-file <ekaitz>divya: are you a seasoned scheme programmer? <divya>ekaitz: I have programmed stuff in Racket, yes. <ekaitz>i don't know about racket but i suppose it's similar <ekaitz>and that would write to that port <ekaitz>and then you can (close-port port) <divya>Is this operating on some system-level with C? <ekaitz>yes, and you can use the append flag to open the port for appending <divya>ekaitz: Here port is like a UDP port that needs to be open or something? <ekaitz>ports are... let's say something like "file descriptor" in scheme <ekaitz>ports are the abstraction for things you can open and close, better said <divya>Indeed, and apparently the manual says the idiomatic way would be to use something like call-with-output-file that automatically takes care of openingand closing the ports <ekaitz>yes, but how can you open for append only? <divya>ekaitz: Right, I guess better to just go with open-ile and then close-port, also display is like writing to the file I guess? <ekaitz>display by default writes in the current-output-port that is the screen, but when you give it a different port it writes to it <divya>Couldn't one use call-with-input-file though? <divya>It is or inputting into the file, right? <ekaitz>it's for inputing, but you can use call-with-output-file but i think that overwrites the file <divya>Wait, overwriting means it erases the previous text? <divya>That is not what I want lol, I just want 2 lines added to the end of the file. <ekaitz>divya: that's why you need to `open-file` with the `append` option <divya>Just to confirm the display and close-port procedures should obviously be included within the open-file procedure so that they can use the port that the latter provides. <ekaitz>(let ((p (open-file ...)) (display "blabla" p) (close-port p)) <divya>Nope, checked out the place where the builder checkout is and I see no change in Cargo.toml <ekaitz>divya: add a phase that fails right after yours and `guix build --keep-failed` <ekaitz>when you do that and it fails, it's going to give you a path with the folder where the build failed <ekaitz>you can jump there and check the Cargo.toml there <divya>ekaitz: The directory is empty :/ <divya>No idea what's happening lol <ekaitz>the output of the `guix build --keep-failed your-package` if the build failed is going to give you a path <ekaitz>when did the process fail? in which phase? <divya>during build, the error is numerical overflow because I made it overlow with (/ 0 0) <ekaitz>better (lambda _ (error "fail for me baby")) <ekaitz>but in any case that should work! <divya>(error "fail for me baby") got it to work? at least cargo build is happening lol I guess <ekaitz>it depends on when you are adding it <ekaitz>if you are doing (add-after 'build ...) <divya>okay this time we have something, let me check the path <divya>Okay we succeeded yet failed <divya>but the change does nothing to the build :) <divya>Cargo and its spurious connection erros, christ <ekaitz>good so you learned something today <divya>haha good night you! Thanks a lot, you've been really helpful. <divya>I appreciate the community, it has motivated me to get started with contribution. <divya>efraim: Any clue about cargo giving spurious network errors? I, with the help of ekaitz, added git-fetch-with-cli to cargo.toml but it still throws spurious complaint. Is this common in cargo-build-system? <divya>I did a local cargo build and while it has other build errors, it has no fetch errors. <divya>If you do find something, I'd be logging out from here and won't receieve notifications, if you'll be so kind, just drop whatever you respond onto my email: divya@subvertising.org <olafes>What's the role of PAM services in guix system? Is it the same as for regular linux distros or is it crucial for some functionality? <sneek>Welcome back olafes, you have 1 message! <rodrigo-morales>[Question] Does anyone know which Guix package contains the executable "sha512sum"? <jaft_r>rodrigo-morales: I just did a "find" on my /gnu/store and it looks like coreutils (including coreutils-minimal) have it. <wakyct>rodrigo-morales: you can also 'guix locate <name>' <elevenkb>i wonder what does one have to learn to become fluent at guix. or to put it another way, how can one learn to be a distro maintainer? <elevenkb>like i'm stuck at some sort of "advanced begginer" level. maybe the answer is teachyourselfcs.com? <wakyct>I feel like you have to be reviewing patches and making packages elevenkb <elevenkb>I have dotfiles with lots of package definitions, just haven't upstreamed them: git.sr.ht/~elevenkb/dotfiles. <elevenkb>right now as we speak I'm trying to package up the latest kanata github.com/jtroo/kanata. <wakyct>it seems like a great help to guix rn would be reviewing patches <wakyct>they've been running patch reviews regularly...maybe every other week I think? <elevenkb>Does anyone know why we have to keep stuff like crates-apple.scm? <elevenkb>I think it has to do with the reason why one has to build the dependencies for all targets, not just GNU/Linux and I have no idea why that is either. <futurile>elevenkb: it's just to satisfy the dependency tree with other packages. They are all set to not to build since we don't have apple/windows builders etc <elevenkb>ah alright, i've given up btw on packaging kanata b.c. kmonad exists and is good enough. <elevenkb>futurile: i'll learn how rust's build system works to do this properly, _after_ learning rust. <futurile>elevenkb: yeah, ironically I don't actually know Rust at all, I just landed up having to package some things, so I've read bits and pieces of the cargo book. Mostly it's just been learn by doing <futurile>elevenkb: it's also a really odd build-system compared to most of the others. If you want to understand the build systems start with the GNU one, as almost all the others are based on it <janneke>ACTION fixes building glibc-static for the Hurd <janneke>in order to better debug what's going wrong when building it for the 64bit Hurd <apteryx>would you run the test suite more often if it completed in about 1 minute? <apteryx>janneke: cool work, thanks for pursuing it! <ekaitz>is it only me or we are shipping an `authenticator` package that has a bug and doesn't run? <apteryx>I see someone submitted 'gnome-authenticator' to guix-patches <Franciman>hi, is there any eta regarding glibc-2.41 being merged? <ekaitz>oh apteryx that i didn't know! thanks <apteryx>it's restrained given it's made of rust ;-) <attila_lendvai>my home reconfigure wants to build guile-3.0.99-git locally, and it fails. there are no substitutes. what could bring it in into my home config? i don't see any explicit reference to it in my config. <attila_lendvai>oh, wait! i have the guile channel. i guess something refers to guile without a version specified, which resolves to the latest guile from their channel <janneke>apteryx: yeah, hoping to have a new version of the 64bit hurd patch set rsn <attila_lendvai>damn, next package to fail is u-boot-2024.01. also without any direct reference to it in my home config. <attila_lendvai>FTR, diffoscope depends on u-boot-tools (!?); the solution was to remove it from my home config. <mfg>Hi, what is the replacement of core-updates? I remember having read that the core-updates branch itself has been removed and i assumed something like core-team to exist, but i'm unable to find such thing :/ <futurile>mfg: I don't think anyone volunteered, partially because it was unclear what it meant I think. There was a discussion on guix-devel as I recall. <futurile>Q: I'm working on Go flatbuffers, we have the C++ and python versions in gnu/packages/serializers.scm (but this doesn't import golang), or put it into one of the golang files? <noneofyourbusine>I'm asking about libc support: I prefer musl over glibc, how much work is this? Am I on my own, would I have to start rewriting individual package specifications? I hope this is a bit easier <mfg>futurile: ah, i see. thanks :) <mfg>that also means no one is actively updating glibc versions and such? <Rutherther>noneofyourbusine: I don't really know much about musl, but I don't think rewriting individual package definitions would be the way to go. Maybe for some packages it would be required, but for most I would expect it is possible to just override their dependencies and possibly arguments. Directly replacing glibc for musl probably won't work, but replacing glibc toolchains for musl ones could possibly? <Rutherther>noneofyourbusine: also you might be interested in package-with-c-toolchain function <csantosb>Someone confirms "guix shell -C antlr4 -- antlr4" is a bug ? It complains about "java: command not found" <raghavgururajan>I forgot this. In `.guix-authorizations` file of a guix-channel, should the fingerprint be of primary key or signing subkey? <futurile>csantosb: no it's not a bug. But it is a weird thing. For lots of things you have to specify the interpreter/compiler needed. So antlr4 requires java at , but the antlr4 package doesn't know that. <futurile>csantosb: so guix shell antlr4 java -- antlr4 : or something like that should work <Rutherther>futurile: I would call it a bug - why is it not wrapped if it's a required dependency? <futurile>Rutherther: call it bug if you'd like - but it's how it works in Guix <futurile>Rutherther: it's the same thing you've been explaining to other people recently, the paths <Rutherther>futurile: it's not, a lot of stuff is wrapped, I would say most of it, and other stuff is a mistake <futurile>OK, fair enough. {not interested in an argument} <csantosb>Then, you need "guix shell -D antlr4 -C -- antlr", not antlr4, which fails <nckx>raghavgururajan: Signing subkey (you'll see some ‘primary: XXXX’ comments in Guix's own file). <Rutherther>csantosb: also I am currently looking at the definition of the package, it's not even that it would not be wrapped. java is directly written to the bin/antlr4 from guile, which is very surprising to me... I don't know why the person writing it didn't use "(search-input-file "bin/java")" (guessing that one should work even for implicit inputs) <csantosb>Java joy of life ! Whatever the way it's been packaged, which package provies the java executable ? 🤔 <Rutherther>csantosb: I am going to make a patch if you won't, my guess is that the person writing it was writing java everywhere when executing it inside build phases (where it's in path) that they forgot to put full path here <Rutherther>csantosb: for locating files, you can use guix locate. Since you have antlr4, you should also have java in your store already. So first guix locate --update, then guix locate java. It's in icedtea package <Rutherther> can I merge my two issues into one? my client somehow told me there was an error when submitting a patch, so I sent it twice, but I've received email from debbugs twice. Or is this job only for maintainers? <janneke>hmm, how do i make a package (/origin?) not use "patch", but "patch/pinned" <Rutherther>okay, I figured out I can merge them myself, but I don't get one thing - how does debbugs know what project I am talking about? Since from what I know it is used for multiple projects, so I would expect it's possible for two projects to have same issue ids <weary-traveler>Rutherther: the debbugs command in Emacs is configured for the debbugs instance used by Emacs, which also happens to be the one used by Guix IIUC <weary-traveler>in particular i've used the mumi instance at times to view Emacs bug reports <Rutherther>weary-traveler: that's what I meant, it's used by multiple projects, not just by guix. But I thought the ids could be the same because of that. But turns out I was wrong in that regard upon closer inspection of ids in issues.guix.gnu.org. I got confused, since it seems most of the issues are guix ones - so the ids are mostly consecutive. <weary-traveler>only seemingly so, given the number of patch submissions on guix <janneke>ACTION has #:tests? #f on the hurd-team branch... :-( <dthompson>civodul: yeah this has been a pain for me for about a week now :( <sneek>dthompson, you have 2 messages! <sneek>dthompson, ArneBab says: I think Guile should never change in a way that breaks flagship projects. Lilypond is one of these: it is the only Guile using project that is the top of the crop of its domain (music engraving). That doesn’t mean that Guile cannot change, but before release of such changes, Lilypond would have to be changed so it does not break. <sneek>dthompson, ArneBab says: a deeper reason is that flagship projects usually cannot adapt easily, because they have to use every trick in the bag to achieve the needed performance. So they can be closely coupled to Guile, and that pretty deep in their core.