IRC channel logs


back to list of logs

***daviid is now known as Guest91543
***Guest91543 is now known as daviid
<wingo>is it a week from guile 3? :)
<wingo>maybe we can get some patches in to fix blockers today and make another prerel
<jonsger>still no fix for this 32bit build issue
<lloda>some of the are old
<civodul>yeah :-/
<civodul>bug triage is hard
<civodul>hey wingo!
<civodul>wingo: i noticed TLS support in (web client) in Guile still lacks certificate verification
<civodul>i could backport it from Guix
<wingo>please do!
<lloda>what about #15228
<lloda>is there anything wrong with the last patches?
<lloda>I think that has been a recurrent question in the lists, or something of the sort
<wingo>how is that bug a 3.0 blocker?
<lloda>oh I don't think it is :-/
<lloda>sorry I missed the context
<wingo>regarding that bug, just documentation missing; link to the patch?
<wingo>reasonable bugfixes that can be done compatibly can land at any time of course :)
<wingo>we don't have to freeze entirely this week but we should be a little more conservative than usual
<lloda>np I shouldn't distract you atm
<wingo>civodul: wdyt of
<jonsger>talking about at least we should make clear in the release notes, that 32bit is not building atm
<wingo>i will just try to fix it, it looks like a simple fix
<jonsger>it's broken since 2.9.3
<civodul>wingo: it's tough! clearly, unwinding just to evaluate the cond clauses and then potentially rewinding seems crazy
<civodul>now, not doing that means that there could be observable changes, in particular wrt. parameters
<wingo>civodul: you are right in a strict sense but i doubt that many people are accessing the dynamic environment from the test of a guard clause
<wingo>i.e. they are usually type predicates
<wingo>so as a tradeoff it might be the best we can do
<civodul>wingo: right, that makes sense
<civodul>i was thinking about current output/error ports which could be different, but you're right that they're typically not accessed from the predicates
<civodul>so i'm in favor of not doing the unwind danse
<wingo>civodul: did you make any progress regarding autoloads and guix?
<wingo>probably we need to roll back the change in guile i guess
<civodul>wingo: it's fixed on the Guix side!
<civodul>that is, if you take Guix master and add "3.0" to, it builds
<civodul>i have yet to address remaining test failures
<wingo>was it a big ol' pain or was it ok?
<civodul>a bit tedious because i had to check every autoload clause, but ok
<wingo>i.e. do we need to be roll back the change in guile or is a NEWS entry sufficient
<civodul>i think a NEWS entry is sufficient
<civodul>but i really don't know if i was the only one doing that nasty thing or not :-)
<wingo>we'll see i guess
*civodul updates (web client) wrt. TLS
<civodul>wingo & all: i've pushed a branch with better TLS support in (web client):
<civodul>that'd be for 3.0
<civodul>but i'd rather have feedback on the API
<civodul>(the code is mostly from Guix)
<wingo>would be ideal to use exception objects of course
<wingo>though i understand if it's not possible
<civodul>i wondered, the rest of these modules still uses symbol + args
<wingo>yeah. can transition later
<wingo>it's fair amount of work and we don't want to block 3.0 because of it
<civodul>i'm emailed guile-devel as well
<dsmith-work>Happy Friday, Guilers!!
***ng0_ is now known as ng0
<civodul>hey dsmith-work
<civodul>Happy Friday!
***janneke_ is now known as janneke
<rlb>wingo: So, 2.2.6 is not in debian testing yet because it can't make it past the build timeout on the arm* buidds, i.e. the debian buildds kill a build if there's *no* output for 150m, and I'm guessing that became the case after the build order serialization changes (i.e. 2.2.4 was fine). I tested on a porterbox, and the overall time is now 502m, but it's that "no output" time that's really matters.
<rlb>wingo: we *may* be able to raise the timeout, but right now, there's no (longer a) per-package timeout, so it'd have to be for all debian packages. I was wondering about the possibility of hacking in some kind of progress canary (perhaps only in the debs) for the really slow phase...
<rlb>s/only in the debs/only in the debian build/
<terpri>rlb, any idea what it's spending its build time on (e.g. with data from strace, ltrace, ...) could be something easily optimizatble
<rlb>It's just CPU, I think, and completely expected right now, i.e. guile's full bootstrap (which the debian packages do -- they don't rely on (nor have) the archive .go files) is *very* expensive in the initial stages.
<terpri>yeah the full bullstrap is relatively slow
<terpri>i have some ideas for optimizing profile hook scripts and such but they won't help if the core build is too slow
<rlb>Ahh, well in this particular (unusual) case, it's not the overall time, that's the problem. It's the length of time with no output to stdout/stderr.
<rlb>(more than 150m)
<rlb>Worst case, if it's not deemed too big a hack by the relevant parties, I can just add a canary to the build that prints something random every so often, but I thought I'd ask in case there was something obvious, and less hackish we might do via guile itself.
<terpri>rlb, do you have an example of where it gets "stucks" under your build system?
<terpri>i'm imaginging it happens during long single-file compiles like "BOOTSTRAP GUILEC ice-9/eval.go"
<rlb>yep, I think that's right -- I'm about to run another build using ts(1) so that I can see exactly where the "long poles" are time-wise, since they buildd admins might be willing to raise the overall limit a bit, but likely not as high as 500+ minutes.
<terpri>could perhaps be useful to add guix-style progress bars for build processes (both for finicky auto builds and better interactive ux)
<terpri>rlb, nice, let us know if you see anything interesting
***Server sets mode: +nt
<janneke>grrr, unfortunate that we have two list-index functions