IRC channel logs
2024-04-13.log
back to list of logs
<stikonas>it probably would just work if we upgrade... <stikonas>maybe some versions of python would need some adjustment though <stikonas>(disable ssl for older python's or patch them) <stikonas>well, that would make sense, but I guess you'll have hard time convincing GNU maintainers of that... <stikonas>even its website says Gnulib takes a different approach. Its components are intended to be shared at the source level, rather than being a library that gets built, installed, and linked against. <pabs3>how much of gnulib code actually gets used in executables on a modern Linux system? I got the impression it was mainly about filling in gaps in older platforms <stikonas>at the very least it's imported ant built into most gnu packages <stikonas>perhaps configure does not use some of those on modern systems... <stikonas>but I think significant part is still used <stikonas>AwesomeAdam54321: well, something within a few months in the repo might still build <Googulator>it would be nice to get in contact with OpenELA (https://openela.org/join/) and ask for .tar.xz versions to be provided (they seem to be relying on GitHub's packaging, which provides only .zip and .tar.gz) <Googulator>the diff from v4.14.336 to v4.14.341-openela is only ~650KiB, so it's probably the easiest to just include it as a patch on top of the last official kernel.org release <Googulator>Making progress on the openssl upgrade: 3.3.0 made curl lock up waiting for a futex, but 3.0.13 seems to work perfectly, including Python <Googulator>so when a new point-release comes out - the existing links break <Googulator>maybe we could get them to put a copy of new releases in /old/<lineage> as soon as they drop, to serve as a permalink <stikonas>Googulator: I don't think we have contacts, but maybe we can ask <Googulator>stikonas, fossy: what are your thoughts on using the OpenELA kernel code? <Googulator>For me, some of the backing entities seem a bit concerning (Oracle, etc.); OTOH they're doing a lot to be transparent, e.g. by listing the source of each backported patch and which higher kernel.org release it came from <stikonas>it's unlikely that even Oracle would just backdoor the kernel <stikonas>there is too much risk of losing business in that case <Googulator>especially since that would also step on CIQ & SUSE's toes <Googulator>one more issue is how we can make a kernel.org->openela patch REUSE-compliant <Googulator>License is obvious (GPLv2-only, like the kernel in general), but who to credit as the patch copyright owner? Is there a better way than to inspect every commit that goes into the patch, and list every author within? <stikonas>well, for author info maybe we can just credit "kernel.org contributors" <oriansj>Companies by default risk too much if they put in a backdoor <oriansj>the reputation loss alone can cost them billions] <Googulator>yeah, "kernel.org contributors" is fine, together witgh maybe OpenELA themselves <Googulator>unless REUSE requires a strict Name <email> policy <oriansj>imagine if an active employee at Oracle did put in a backdoor in the kernel, it wouldn't be too long before it is found and then you know Oracle would cut the employee, legal would definitely get involved just to put the losses on that employee as fast as possible. <oriansj>if it is samsung which hide which employees are responsible for the commits, they'll end up either having to make their internals known or no one will ever trust them again.