@Rairii@julia Yeah that too, the license more matters when you want to make modifications and share them, without say having a Nintendo throwing you a DMCA.
@lanodan@julia@Rairii I expect distros like debian have removed those from the source tarball... Not like java and c# are very auditable as an ecosystem anyway.
@lanodan@julia@Rairii I suppose java objects and some others might be the exception, as really the ecosystem doesn't make it easy to properly rebuild everything, but as the top of the page states, the DFSG requires source code to be available for everything shipped in the distro, and stripping blobs from source archives is part of that goal. Debian doesn't ship source-less blobs outside of the "non-free" repo.
@lanodan@julia@Rairii Because... sometimes the source is just complicated enough that reading the generated binary and/or observing it running *is* your best bet at understanding it :akko_aaa:
@lanodan All those files have source equivalents now*. It's definitely very strange that binaries were put there instead of just compiling during the build. Both csharptest and javaversion are tiny but compiled with ancient toolchains which means it's very annoying to reproduce them exactly. Auditing is quite easy: `javap -p -c` and `ikdasm` (from mono) can show the very few instructions making up those files – there's nothing funny going on there.
@yyp As far as I know for java you could use -target 1.1 with javac. But well the only javac I got was an old version of eclipse-ecj (as I failed to bootstrap OpenJDK). And failing that it should still be proper documented so it can be remade for modifications when needed (in fact Guix and quite few other distros keep ancient versions around as mere build-dependencies).
And recipes are required per GPL, at least GPLv3's "Corresponding Source", which GNU gettext is licensed under.
@lanodan The javaversion.java file has a command to build it (not sure if it counts as a "recipe").
With some tweaking I managed to build the binary with openjdk-jdk8u which is the oldest version I could get on Alpine (javac -d . -target 1.1 -source 1.2 javaversion.java) but it still has a 3 byte difference from the original. Not sure what's up with that.
As for C#, well, there are no instructions or compiler versions anywhere. Using standard csc from the latest mono gives tons of differences.
@lanodan I've managed to get a 100% match for javaversion.class.
Unfortunately, the provided source is not correct. The binary class file contains debug symbols, in particular line numbers. At some point the source was modified and had its line numbers shifted which caused a mismatch when I recompiled it. I "fixed" it by deleting 3 comment lines from the header to compensate for the shift.
@lanodan I've got a few things working with csharpexec-test. I could get a build pretty close the shipped one with Mono 2.6.7 (running in Wine because I couldn't build a native version, oops). It has functions in the wrong order and some field values have minor differences but it's probably the closest I could get to a complete match. Also, C# assemblies have a random build ID so a 100% would never be possible. This project took way too much time, the findings are impractical, but it was "fun"