***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 <civodul>wingo: i noticed TLS support in (web client) in Guile still lacks certificate verification <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? <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>i will just try to fix it, it looks like a simple fix <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>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>that is, if you take Guix master and add "3.0" to configure.ac, 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>but i really don't know if i was the only one doing that nasty thing or not :-) *civodul updates (web client) wrt. TLS <civodul>but i'd rather have feedback on the API <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>it's fair amount of work and we don't want to block 3.0 because of it ***ng0_ is now known as ng0
***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>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