<mihi>ah ok, seems that mes fakes syntax objects as vectors with 'syntax-object as first element. To be honest, I thought about vectors with '<syntax as first and '> as last element, too, when I was still unsure how to avoid the segfaults in guile when printing syntax objects during early bootstrap. But then I got the real syntax objects working. <janneke>well, very exciting stuff! but for now <stikonas>building it is not too hard, but a bit annoying to install into suffixed subdirectory <Hagfish>i'm hyped for another step being added to parts.rst <Hagfish>nevertheless, there's no harm in considering a change to some pre-existing work to find a more correct way to handle suffixed subdirectories, etc. <pabs3>re detecting generated files, Debian has a tool called suspicious-source (in the devscripts file), but it needs to be split out of devscripts and grown into a separate project <pabs3>er, s/devscripts file/devscripts package/ <Hagfish>i wonder if it would be easy for a Debian developer to work out which files are read during the build process for a package, and write a metadata file describing this <Hagfish>the format would allow regexes, so they could say that all *.c or *.py files are input source code, and *.png files are images, etc. <Hagfish>i suspect that some packages would have some surprises, though <pabs3>I remember seeing a project that did that via ptrace (was more generic than just Debian though) <Hagfish>i guess in some cases the "build" process just copies "source" files into the output directory, but maybe that could be detected as suspicious <pabs3>but really, ptrace isn't enough, since obviously /dev/null isn't part of the source for foo.o even though gcc might access /dev/null <pabs3>but I think it had some heuristics to avoid that sort of association <Hagfish>yeah, those sorts of issues would be easy to spot when looking at the stats across hundreds of packages <pabs3>btw, *.c and *.py and *.png are not always source, sometimes they are generated from other things <pabs3>*.png is more often *not* source, since that could be SVG or XCF etc <Hagfish>i don't think Debian has been very strict about interpreting the GPL that way regarding images <pabs3>I agree. DFSG item 2 is exceptionally fraught in Debian <Hagfish>“The source code for a work means the preferred form of the work for making modifications to it.” <Hagfish>that's the line from the GPL that comes to mind <Hagfish>ah yes, fonts are particularly troubling <pabs3>yes, but not as troubling as machine-learning stuff like tesseract <Hagfish>"Hinting in TrueType contains ‘real’ programs adapting these shapes to low resolution grids and making them legible on screen. These programs are distributed in a Turing-complete assembly-like language interpreted by a stack-based virtual machine." <Hagfish>"This game has another interesting issue: a license that forbids selling it alone and allows selling it in larger software distributions. Well-known free licenses for fonts like the SIL Open Font License have the same restriction. It’s ‘useless’ since distributing the work with a Hello World program is allowed and this makes it a free software license." <Hagfish>i was never convinced by this argument <Hagfish>surely a judge would look at the intent of the license, not the clever and self-serving interpretation that a software developer dreamed up <Hagfish>and i say that as a developer who likes dreaming up clever interpretations of legal ideas :) <Hagfish>i suppose one reasonable line which could be drawn is to say that the software it is distributed with must be bigger than the font itself, and use the font in some way <Hagfish>or, in the case of the game, be capable of running the game? ***ChanServ sets mode: +o rekado
<siraben>GHC compatible import declarations too, no less. <Hagfish>"Continuing our RPG analogy, we liken modules to parties of heroes." <stikonas>fossy: pder: not sure what to do with one aclocal.m4 file in binutils... <stikonas>part of it is autogenerated, the other part is takem from some other file with modifications <stikonas>hmm, maybe we can somehow disable that folder entirely... <fossy>that should be Internationalizations aka locale and crap <fossy>sorry I had an assignment that refused to export so I didnt get much done last night. I shall revirw now <stikonas>but I haven't dealt with that aclocal.m4 file <stikonas>also need to recheck latest bash for similar issues... <fossy>that looks good. Ill open an issue for intl <fossy>we will probably end up needing gettext eventually <civodul>janneke: i hear Mes 0.23 is out, woohoo, congrats! 🎉 <stikonas>fossy: yeah, gettext is needed but that aclocal.m4 file is not very obvious anyway <stikonas>it's probably modified version from very old gettext <stikonas>on the other hand, those aclocal.m4 files are at least much more readable and maybe can even be considered source... <stikonas>definitely more readable than configure scripts <janneke>dannym and i were kinda "waiting" until the full arm bootstrap was in guix, but that's been going on for months now and hopefull the last mes bug for arm was fixed about a month ago <janneke>yeah, it's been quiet a ride, again :) *fossy is looking forward to riscv personally <fossy>Im waiting for pine64s board <fossy>stikonas: yeah but no SOC or anything yet <stikonas>fossy: ok, bash I think is clean from autotools generated files. There were two suspicious files aclocal.m4 and config.h.in but they looked handwritten to me and both are in AUTHORS file