<rlb>Is stable-2.2 a "spur" branch now, or is the intent to merge it up to 3.0 now and then? <rlb>In the THANKS, what's the full distinction between the first and last sections? i.e. trying to figure out what contributions go in which section. ***daviid is now known as Guest60468
***Guest60468 is now known as daviid
***catonano_ is now known as catonano
<iv-so>hello, I have troubles with guile3.0 cross-compilation (host: x86_64, targets: aarch64, armv7l; host: x86_64-musl, targets: aarch64-musl, armv6l-musl) <iv-so>builds are failing at langauges/elisp/boot.el, I found two mentions of the same error in GNU debuggs, but no sign of solution ***apteryx is now known as Guest64583
***apteryx_ is now known as apteryx
***daviid is now known as Guest77937
***jonsger1 is now known as jonsger
***jonsger1 is now known as jonsger
<mwette>Hey stis, and all other lambda-heads! <roptat>I have a commit object, and when I try (commit-author commit), I get a signature object, but I have no idea how to get the name of the author <dsmith>iv-so: Interesting. Trying to open file #f ***jonsger1 is now known as jonsger
<rlb>civodul: did you happen to see my questions yesterday? i.e. is stable-2.2 merged up to 3.0, or is it a "spur" branch now? And "In the THANKS, what's the full distinction between the first and last sections? i.e. trying to figure out what contributions go in which section." <manumanumanu>I just got bitten by the unhygienicness of procedural macros: I had no idea that bindings introduced within the scope of a syntax-case macro can collide. If I insert #'temp into a macro, and then another #'temp later on, but still within the same expansion, they can collide :( <civodul>rlb: i hadn't seen your questions, sorry <civodul>stable-2.2 hasn't changed much if at all since 2.2.7, but we could consider cherry-pick some changes from "master" and releasing 2.2.8 <civodul>as for THANKS, i think the headings are quite clear, but i wonder if it makes sense to keep it like this <civodul>we tend to credit people (for bug reports, etc.) directly in commit messages <rlb>Oh, the context was just wondering whether if I have some (small/appropriate) changes to apply that could go in both, what's the criteria/process, i.e. should I cherry pick to both, add it to 2.2 and then merge up, etc. <civodul>well, it's not well defined i guess :-) <rlb>say that trivial doc change, or... <civodul>i'd start by cherry-picking things that landed in master after 2.2.7 was released <civodul>there may be a few interesting commits <rlb>I could leave the doc change off of 2.2, and I might, but just wanted to make sure I knew whether 2.2. was still intended to be merged up, or if it was already considered a "spur" branch, etc. <rlb>And wrt THANKS, I was mostly just trying to figure out if the last section was "all authors ever", or if the first section was for people who actually contributed code, and the last section was for things like bug reports, etc. <rlb>s/authors/contributors/ <rlb>In this simple case, it was the commit sent to restore a single comment line that was accidentally dropped in the past. Do they go in the first section or the last section... <rlb>(a comment line in guile.c, fwiw) <civodul>yeah, stable-2.2 is not merged to master because nothing happens there :-) <rlb>OK, just wanted to make sure I knew what the intentions were -- sounds like it's intended to be a spur branch for now. <civodul>i'm actually unsure what "spur" means in this context, but i'd say it's a dormant/stale branch <rlb>I mean a branch that's not merged up (sorry, railroad terminology I think). <rlb>i.e. it doesn't connect back to anything else. <rlb>And so wrt THANKS is the "rule" that any commit author goes in the first section, and everything else (other than libs) goes in the last section? (And is the last section, "since the last release" or covers the whole project history (in which case I guess the first section merges into the last eventually)? <rlb>The fact that the last section didn't say "since the last release" explicitly is one thing that made me wonder. <civodul>rlb: i'd say do as you see fit for now, and let's discuss with wingo about deprecating it altogether <civodul>make sure to credit people (bug reporters in particular) in commit logs <civodul>so that we can then maybe have THANKS point people to the Git history <rlb>Oh, I'm putting it in the commit messages too (always try to do that), but just wanted to make sure I followed HACKING's request to update THANKS correctly as well. <rlb>i.e. I was assuming that my commit should *also* update THANKS (thought that is a potential source of merge conflicts). Was that not right, i.e. should I just put the info in the commit message? <civodul>rlb: i think it's right to do that, but i think we should consider changing the rule going forward :-) <rlb>OK, so I'll assume the first section is for any commit authors, the last is for anything else, and I'll let y'all worry about the rest of what the last section means :) <spk121>Gtk is a aggravating toolkit. I had the Stockholm syndrome, but, after months away from coding and looking at it anew, ugh. :-) <rekado>this mumble thing seems to work fine <rekado>I do need to keep updating the avatar location, even if it hasn’t changed, because if it’s not updating anything my “game” is kicked out of mumble <rekado>I’m not a fan of delegating setup of mumble to users; perhaps there’s a config file I can generate to take over some of that work. <rekado>some of the work will need to be done by an extension of the murmur server, e.g. to enforce muting in certain locations <rekado>it’s a bit annoying that none of this can be extended with Guile… <civodul>rekado: we'll have to hold an on-line event to test drive whatever you come up with! <mwette>manumanumanu: I was bitten by the syntax hygene issue also. I wonder if somehow gensyms could be module-unique during compile and then relocated (in the elf sense) during load.