IRC channel logs

<fossy>melg8: you should squash some of the fixing commits in ur PR, the branch is v messy

<melg8>okay) i've asked on channel some time ago (beginning to implement this flag part) can you elaborate on your vision?

<melg8>1) single file with all future flags from sysa, or a bunch of files each for it's own usecase. 2) single more general option - like enforce-reproducibility or few more small one (force-timestamps, remove-unreproducible-logs etc)? 3) create this config file inside repo and just copy it to sysa, or combine it by options to console?

***stikonas_ is now known as stikonas

<fossy><melg8> 1) single file with all future flags from sysa, or a bunch of files each for it's own usecase. 2) single more general option - like enforce-reproducibility or few more small one (force-timestamps, remove-unreproducible-logs etc)? 3) create this config file inside repo and just copy it to sysa, or combine it by options to console?

<fossy>combine by command line flags: a single file could be better but a bunch is easier.

<stikonas[m]>fossy: single file might be easy if we source it, I.e. if it contains var=value entries

***Noisytoot is now known as Sigyn

***Sigyn is now known as Noisytoot

<melg8>Hi, can maybe somebody help, i'm running same live-bootstrap with qemu but with two different kernels - 5.4.100 and 4.4.267, and i get different binaries for coreutils 8.32. Inspection for program "yes" for example show difference as such:

<melg8>infomap.4080 vs infomap.4077

<melg8>C.18.4821 vs C.18.4818

<melg8>old_line_number.34.18 vs old_line_number.34.15

<melg8>old_file_name.34.17 vs old_file_name.3414

<melg8>thats with readelf --wide --symbols {}

<melg8>any ideas, what this is and why this happens?

<stikonas>maybe best to dissassemble first

<stikonas>and then run diff

<melg8>i use diffoscope it shows whole thing

<melg8>18 ··0x000000f0·6c6c6172·795f696e·666f0069·6e666f6d·llary_info.infom 18 ··0x000000f0·6c6c6172·795f696e·666f0069·6e666f6d·llary_info.infom

<melg8>19 ··0x00000100·61702e34·30383000·76657273·696f6e2e·ap.4080.version. 19 ··0x00000100·61702e34·30373700·76657273·696f6e2e·ap.4077.version.

<melg8>for example

<stikonas>yeah, but this is unreadable...

<stikonas>I would first run objdump -D

<stikonas>on files

<melg8> logname.c 358 logname.c

<melg8>359 emit_ancillary_info 359 emit_ancillary_info

<melg8>360 infomap.4080 360 infomap.4077

<melg8>361 version.c 361 version.c

<melg8>362 closeout.c 362 closeout.c

<melg8>363 file_name 363 file_name

<melg8>364 ignore_EPIPE 364 ignore_EPIPE

<melg8>365 exitfail.c

***ChanServ sets mode: +o rekado_

***rekado_ is now known as rekado

<melg8> https://ibb.co/K74zLJV

<melg8> https://ibb.co/T29CRyt

<stikonas>hmm, no idea ...

<stikonas>maybe some defines were different

<stikonas>when compiling

<stikonas>I'm not really sure what those numbers e.g. 4080 vs 4077 mean

<melg8>that's interesting, gnu missing

<melg8> https://ibb.co/DY0yZ6s

<melg8>(for tail program)

<melg8>hmm i see i guess

<melg8>it looks like few lines were missing, and this is line numbers or identifier numbers - which decreased

<melg8>all by 3

<melg8>@fossy my mr found really interesting issue. It happens so on kernel 4.4 (or what concrete number in ci idk) nanosleep works really well, so it doesn't need fix-up implementation from gnulib, but newer kernels (like 5.4) have buggy implementation, and they need this additional function. Because of that - nanosleep.c is not linked in case of 4.4 and

<melg8>is linked in 5.4 to each of coreutils binaries. And than - hashes mismatch strikes. What roads would you suggest? i can try to patch this (by artificially introducing error code to test, which is run at configure time, that would force it to always use implementation from gnulib when compiling coreutils.)(im in process of testing this solution), or

<melg8>just update kernel to newer in ci (as stikonas suggested)? or you see other possibilities?

IRC channel logs

2021-05-11.log