On Sat, 2017-01-21 at 12:39 +0100, Fabian Greffrath wrote: > I find this by far the most convincing argument, although I still find > it difficult to accept that it should make a difference for Debian as a > mere downstream distributor. We provide many packages with fonts in OTF > format and while this is accepted as a proper source for some, it is not > for others because of upstream design decisions? Upstream decisions are the best proxy we have for preferred form for modification, since they are the ones who are working on the project. Lets take the example of the obfuscated Xorg nv driver. NVIDIA had some released driver code, but they were not developing that code. Instead they had some secret internal code that they developed. Their release process was to automatically obfuscate the code by expanding macros and replacing constants with numeric values and other things. Clearly their preferred form for modification was that internal code and not the released code. This was a DFSG violation because upstream and Debian users did not have equivalent access to the work. Another example is Perl. Perl has a Configure script that the Debian Perl Team has declared is source. Helmut Grohne found a bug in that script that prevented it from working in cross-compilation scenarios. He attempted to send a patch for it upstream but discovered that it was in fact generated from another file (so wasn't source despite what the Debian Perl team said) and the issue was already fixed in the other file but the Configure script hadn't been built from source in ages and it couldn't be built any more. This highlights that we need to be always (re-)building from source in order to detect FTBFS and to prove to our users that they have the freedom to modify and rebuild Debian. Both of these are slightly different to Firacode, which is the fair bit more straight forward issue of non-free Build-Depends. Based solely on the commits in their github repo, the source for Firacode is the .glyphs file and not the TTF/etc files. To convert that to the other formats, you currently need the proprietary Glyphsapp. According to Debian Policy, that means the font belongs in contrib because we can't guarantee to our users that they will be able to modify the source and rebuild the font using only packages in Debian main. Upstream and Debian main users do not have equivalent access to the work. > Well, RMS himself told me that the Type1 format in which the fonts are > distributed is considered a proper source format. Apparently he doesn't > even care about what tools upstream used to create the fonts as long as > they are distributed in a proper source format. The point I've been trying to make so far is that what the proper source format is, is completely dependent on the development scenario. It can be the source format or it can not be the source format, depending on the development processes upstream chose for the fonts. Quite unrelated to that is whether or not it is a good choice of source format or not. As a software developer used to version control I find binary formats a poor choice but upstream might have really great font tools that deal fine with binary fonts by doing visual comparisons. > Agreed, but I don't think that this (i.e. "is it easy or even possible > to create a patch that upstream would outright accept in that form?") > should be a criterion to decide if a package is suitable for Debian > main or not (as long as it is possible to create the patch in the first > place, that is). Ack, I wasn't suggesting that. I was suggesting that this is the best way to determine which files in the upstream repository are source and which are not source. Doing that would really be forcing the issue though. You really don't need to go that far, for Firacode you just need to look at the commits in the repository to determine that. -- bye, pabs https://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part