IRC channel logs
2023-07-13.log
back to list of logs
<oriansj>and github just became unusuable without javascript <oriansj>Well, I have already mirror'd all of my work to sourcehut/savannah; I was just surprised that I can't even see other people's code without javascript <oriansj>so in many ways I have already moved away from github for anything but pushing a few new commits; and pulling from a few repos before merging locally <pder>fossy: I looked into gcc-13.1.0 creating binaries that crash on startup and it appears that disabling ssp fixes it. <pder>I tried dropping the libssp_nonshared patch and passing --disable-default-ssp to configure and was able to build working binaries. <pder>I tested rebuilding a couple of packages like sed, make, and tar and gcc with ssp crashes on all of them <pder>With the patch, they work <doras>stikonas: I'd like sysc's /init to clear environment variables before doing anything meaningful, to isolate it from the environment in which it can run. How would you approach this? <doras>Maybe also sysb's, to keep things consistent. <doras>The options are likely to either move logic from /init to the respective ./run.sh scripts and call them with env -i, or maybe to use #!/usr/bin/env -S -i bash as the shebang. <doras>The latter assumes that we have a capable env available when /init is executed in both cases. <doras>I guess it would have to be added to sys_transfer and then maybe removed before coreutils is installed. <doras>A third option, which is not as comprehensive as the first two, is to keep /init as-is and only run ./run.sh with env -i. <stikonas[m]>I think I might be leaning for simpler 3rd option... <stikonas[m]>Nothing particularly interesting happens before run.sh <stikonas[m]>Transferring env to sysc and removing before coreutils is installed sounds a bit overkill given that coreutils installation is the first thing to run... <stikonas[m]>Though I guess moving logic to next file is also fine <doras>stikonas: I think the third suggestion has a place regardless of the additional value that the first two may bring. I think I'll create a PR about it anyway. <doras>With some basics tests it seems that using declare -x instead of export may be a good minimal-impact solution here, since it exports the variables only in the scope of the function where it's called. What do you think? <stikonas[m]>Dor Askayo: yes, ideally we have each function in subshell <doras>stikonas: it seems that both `local` and `declare -x` work. Do you know which is more appropriate? <doras>stikonas: I haven't ran it through the bootstrap yet, just playing with test scripts to understand what should and shouldn't work. <doras>stikonas: "local doesn't export" is what I thought too, but it seems that it does. Well, if you define "export" as "pass environment variable to passed to child processes". <doras>stikonas: never mind, I figured it out. I was playing with the `SOURCE_DATE_EPOCH` example, which is already exported globally using `export`. So if you "redefine" an exported variable with a `local` variable inside a function, it does not remove it from the exported list and any command executed from the scope of the function (or nested functions) would inherit this "local" environment variable. <doras>However, when it's not exported globally using export, it does indeed remain local to the script and not exported to child processes. <doras>On the other hand, declare -x, when used in the context of a function, exports the variable to child processes even if it's not declared globally with export, but only for commands executed within the scope of the function (or nested functions). <doras>stikonas: so I think `declare -x` is may be the appropriate candidate when we actually expect child processes to consume the variable. <doras>stikonas: digging in some old docs for 2.05b, it seems that it should be supported. <drakonis>specifically its ability to select which encodings can be used on a per instruction basis and being able to write the output encoding into the source file <doras>Never mind, I suspect it's a DNS connectivity issue. <stikonas>doras: by the way, have you tried pder's patch <doras>stikonas: I haven't. I guess I missed it. Where can I find it? <stikonas>though it's probably just a workaround, in principle SSP shouldn't crash <pder>Figuring out a way to enable ssp with gcc 13 and musl should be possible, but just needs more investigation. <stikonas>yes, which is why I don't mind merging this first <stikonas>hmm, I've just though of another small speedup in sysa <pder>ok, still need to update checksums and maybe a bit more cleanup <stikonas>it should be possible to build mes before we build libc+tcc <pder>stikonas: do you have any thoughts on the pregenerated files in nyacc and how to solve that? <stikonas>pder: well, janneke suggests waiting for mes 0.26 (current version is 0.24) <stikonas>otherwise we need to hack some nyacc modules to be mes modules <stikonas>but I'm not very familiar with what exactly this means <pder>what is the difference between mes-m2 and mes? Is it just that mes is the interpreter code compiled by mescc? <pder>and mes-m2 is the same code compiled by M2-Planet? <pder>Do they have different feature sets or just differences in performance? <stikonas>should be the same but mes-m2 fails to compile tcc (crashes) <stikonas>anyway, this would be replacing interpreter with better interpreter, so I don't see any drawbacks... <stikonas>(and possibly need to redefine MES to be /usr/bin/mes instead of /usr/bin/mes-m2) <pder>So after building mes-m2 you immediate recompile mes with mescc? Then compile the mes C library? <stikonas>so at the moment we build mes-m2, libc (part needed to rebuild mes) libc+tcc (part needed to build tcc) mes and then tcc <stikonas>I think mes-m2 libc mes libc+tcc tcc would work <stikonas>also another small task if you want, I think we don't install libbz2.a and the header in bzip2 package... <stikonas>so we can't enable bz2 module in python3.11 <pder>yeah, looks like we only install bzip2 bunzip2 and bzcat <doras>It will likely take a while and doesn't show live output for live-bootstrap. Though I set the JOBS configuration in bootstrap.cfg to 12 cores, so maybe it will at least be quicker. I hope we don't have reproduciblity issues with build concurrency. <doras>This is from a bwrap bootstrap and my branch to remove some exported variables that shouldn't be exported. <doras>I don't see how my changes can cause it, so I was wondering if anyone had seen it before. <pder>doras: I didn't update the checksum on the gcc-13.1.0 so you might get a failure there <doras>pder: thanks for the heads up. It's fine though, I set it not to fail due to checksum changes (`UPDATE_CHECKSUMS=True` in `bootstrap.cfg`) <pder>ok, good. didn't want you to be disappointed after waiting several hours <doras>Regarding the python-2.5.6 failure, I'll try bootstrapping again to see if the issue is consistent. <stikonas>it would also be good to add ncurses/libreadline in sysc...