It's not very popular, but I wonder if signing release tarballs with the release manager's private key would go some ways towards alleviating xz-esque woes, at the very least making distros aware that an upstream has changed hands and having to do due diligence to fix their builds
@drewdevault Many projects have more steps than just "autoreconf", for instance curl also needs extra steps to update the version in the header files and to generate the changelog file (see https://curl.se/mail/lib-2024-03/0062.html and https://github.com/curl/curl/blob/curl-8_7_1/maketgz). Unfortunately, there's no standard command like "./configure" or "make dist" to do these steps, each project does it differently, some have shell scripts (which might need uncommon setups), some have a list of commands in a text file somewhere...
anyone know of a common git workflow that would result in 4 commits with 2 separate authors all sharing identical commit timestamps and author timestamps?
@bagder These version numbers are not enough, when I tried earlier I noticed that the generated files seemed to contain patches added by Debian or Ubuntu, you should specify the exact versions including the distribution-specific revision (from dpkg -l).
The latest from Ubuntu 23.10 worked best for me, these were probably what you used, but having the exact version makes it easier to reproduce in the future.
@bagder As to the best place to document, my suggestion would be to (once you have determined the set of tools which matter and how to obtain their exact release) change your script to put the relevant versions in a text file somewhere within the tarball itself.
Can I just say that I have created #curl releases "the #xz way" since the 90s: I generate the release tarballs on my machine. It makes the tarball have (generated) files included that are not present in git. It's a feature. But it also makes it harder for observers to figure out if the additional files are fine or not.
@bagder It might be enough to just say for instance "this tarball was generated from commit nnnnnnnn on Debian stable up-to-date as of xxxx-xx-xx using autoconf yy.y" (and generating it from a clean checkout). Someone who wants to verify can download the packages as of that date and that autoconf version, run the script to generate the tarball, and compare; the resulting diff should be small enough to audit quickly by hand. That should be low enough effort for both you and the verifier.
@bagder I tried it just for fun, got curl 8.7.1 from the github release page, unpacked within a docker.io/library/debian image in podman, installed "autoconf automake libtool make libssl-dev libz-dev", ran "autoreconf -fi" and "./configure --with-openssl" and "make dist", and other than missing CHANGES and vcxproj files, the resulting diff from curl 8.7.1 from curl.haxx.se was small enough to review by hand in just a few minutes. It should probably be easy to get an even smaller diff.
Hot take: video games have peaked in terms of resource requirements and there's not much need to keep making better and better GPUs etc. Hardware has been more than enough for several years now
@drewdevault I don't think comparing sales of the PS4/PS5 with the switch is useful, due to the difference in form factor. The portable form factor is just that much more convenient than the fixed form factor. It's the same reason many people buy laptops even when a desktop would be more powerful and cheaper (and often more durable too, due to the ease of swapping pieces).
I don't understand people longing for the '90s and early '00s. They fucking sucked. 90% of the problems we're facing now originated during those years.
@gabrielesvelto For me personally: we had just gotten out of the military dictatorship. The Plano Real finally controlled the hyperinflation, and we had for a while parity with the USD, making it less expensive to travel or import electronics. Speaking of electronics, the "Reserva de Mercado" ended, meaning we could (and I did) buy the same computers and operating systems the rest of the world was using. On a more personal note, several of my now deceased relatives were still alive.
@kernellogger@SchwarzeLocke I vaguely recall reading that Linus currently uses Fedora, and Fedora comes with selinux enabled by default, so it might just be the case that he didn't feel a need to disable it on his machine.
Hearing reports that Baldur's Gate 3 is totally unplayable in Act 3 on Steam Deck.
This is again why I keep saying people doing "Best Settings" guides are a load of rubbish, because it's always from people who haven't actually played it through.
Also shows Valve need to improve Deck Verified / Playable to truly take into account performance through longer games - which clearly many times they are not.
@gamingonlinux I had expected that the popularity of the Steam Deck would mean that game developers would test on it during development, making it a useful baseline for the amount of computing power a game requires. I guess we're unfortunately still far from that ideal.
@bagder@utzer I haven't used Windows for a long time, but I recall reading that, on modern Windows, a lot of the files in system32 are actually hardlinks to files in winsxs. If that's the case for curl.exe, just restoring the file might not be enough, since windows update might need it to still be a hardlink to the correct place.
The correct solution is most probably to use a command to reinstall the file from the original copy, be it winsxs, the install media, or even windows update.