IRC channel logs

<fossy>who runs files.bootstrapping.world?

<stikonas_>fossy: oriansj

<stikonas>oh you need to add new files there?

<fossy>nah, was just wondering if we could get http (non-https) access?

<fossy>because atm it 403s http to https

<stikonas>oh yeah, that's common advice in all configurations these days

<fossy>yea, unfortunately not exactly ideal for us lol

<stikonas>yeah...

<stikonas>upstreams are also moving to https only...

<stikonas>well, we do need to download over https when developing (adding / upgrading packages), even if we commit http url to sources

<stikonas>but yes, http would be nice to have

<stikonas>especially since later the process is checksummed

<stikonas>well, having our own mirror network would workaround this https only issue

<jackdk> https://scotthelme.co.uk/we-dont-do-https-for-backwards-compatibility/ What about `Content-Security-Policy: upgrade-insecure-requests` and configure the 301+HSTS only if the client sends `Upgrade-Insecure-Requests: 1`? Seems like a good blend of best practice and not shutting out HTTP clients

<stikonas>jackdk: but some upstreams are very against any http support

<stikonas>e.g. openssl was one of them

<stikonas>perhaps unsurprising

<stikonas>just as compilers often want to depend on their own language

<jackdk>Yeah, that's about what I'd expect from them. But it does look like a reasonable configuration to use for any mirrors we stand up, and something to lobby for that doesn't stop modern clients from upgrading

<homo>alternatively it's possible to have proxy that strips s out of https...

<stikonas>or that alternative p2p mirror network that we discussed...

<stikonas>though that's quite a bit more work

<jackdk>I argued on the github thread that HTTP mirrors are easiest and we can then use them at web seeds for torrents if we want to go P2P later

<aggi>https/ssl protocol was broken before with the TLS transition excluding protocol versions/ciphers/hashes etc

<aggi>another example, recently i tried to access codeberg with dbclient ssh and got rejected due to some server side protocol implementation flaw

<aggi>various distfiles vanish quickly from gentoo mirrors, gladly gentoo is keeping many(!) hashes/checksums inside their portage tree

<aggi>but i've spotted mismatches once or twice with some tar.gz fetched from github.com already

<aggi>too gentoo got a separate portage tree archive, for distfiles up until year 2013 with manifest/hashes

<aggi>sometimes it's not easy to spot specific versions with git log, nonetheless they probably hashed almost each and every single distfile version that existed

<aggi>redhat/fedora/centos bundles variou source-dvd.iso with various releases

<aggi>i downloaded the redhat9,fedora7,centos6; and i quit syncing gentoo distfiles year 2022 when my 1.5TiB raid hit out-of-space with it

<aggi>a day ago, i tried to find various versions of iptables/iputils/networking-utils that matched linux-2.x abi

<aggi>some of this already vanished from official mirrors, but i could find what was needed

<aggi>currently i am backporting yet another patch to linux-2.4, that redhat missed for full unicode support for linux console

<aggi>since i've begun runtime-testing of i486-tcc-linux-musl.iso distribution

<aggi>i need to backport nilfs2 to linux-2.4 soon, seeing to this does work, because to my knowledge this is the only filesystem with 64bit timestamps that linux-2.4 may support

<aggi>while ago i've written a tiny fsck/valseg utility for nilfs2, that verifies all segment crc, which greatly raises confidence into what was stored for archival

<aggi>i gained a little insight into nilfs2 administration, from a practical standpoint

<aggi>if the snapshot/checkpoint feature was desireable, which it is, the garbage-collector must be activated, with a long protection-period, which mustn't be altered

<aggi>i still need to do a little forensics, why some linux-5.10 with a nilfs2 rootfs is leaking disk-space continously

<aggi>that's something which isn't noticable with any other filesystem

<aggi>ideally i can fully fully transition my development host back onto linux-2.x soon

<mid-kid>Trying to update the gentoo bootstrap, building gcc:14 using the supplied gcc:13 isn't going so well

<mid-kid>wonder if anyone has tried building gcc 14 on live-bootstrap yet

<mid-kid>something about dynamic relocations in a read-only segment

<mid-kid>I assume something hasn't been properly compiled with -fPIC when it should've

<stikonas>no, I haven't tried building GCC 14 there

<stikonas>I guess as a short term workaround you could try to build Gentoo with gcc:13

<stikonas>and then use gentoo scripts to update to GCC 14...

<mid-kid>yeah I was thinking of something like that but eh

<mid-kid>I'll look into it for a bit

<mid-kid>but my uncle is complaining about the computer's noise so I'll have to resume after the holidays

<stikonas>yeah, that's fine...

<mid-kid>.fave

<mid-kid>wrong channel

<Googulator>mid-kid: Merry Christmas! :)

IRC channel logs

2024-12-24.log