On 2/23/22 12:51 PM, Andreas Tille wrote:
Am Wed, Feb 23, 2022 at 12:24:41PM +0530 schrieb Nilesh Patra:When I looked at the source, it comes with a few minified javascript files, which have sources so I can manage this. What looked like a bit of a problem to me is that it vendors several '.woff/.woff2' font files (binaries) in "inst/fonts" directory, some of which is basically fetched from google fonts. Since this was potentially non free, I opened an issue upstream[1] -- they are very cooperative and gave prompt responses. As they mentioned, the license for fonts seem to be compatible with DFSG[2]. So do you think we can directly distribute these binaries?I can only guess here: My reason to delay the work on this is, that I'm afraid that ftpmaster wants to see the source of these font files. Sometimes it makes sense to package these separately.
This was what I was fearing. I need to admit that this is a 'gigantic' waste of everyone's time to be doing this. Even if we give out sources It looks * very * unlikely for someone to edit this in what is a part of an * R * package.
I am only afraid if these could be considered binaries w/o source, and lead to FTP master rejecting this? Do you think that's the case?I think so.
Hmm, however, on seeking this on codesearch.debian.net, I came across shinydashboard, see here[1] which in principle also looks like a source-less binary and appears to be same ttf (binary) stuff but this is in the archive. Can you please quickly check this up with Thorsten/another FTP master over email/instant message? [1]: https://sources.debian.org/src/r-cran-shinydashboard/0.7.2-1/debian/copyright/?hl=23#L23
Do you think upstream could do $something about this?Providing source and binary would be helpful. As I said above we might also consider adding a font package.
Yes, but we need sources for that, right? On quickly checking it, I could not find any 'source' package that we can get and compile. Additionally, can you address your findings on the github issue please? That'd help track things smoothly.
Admittedly, otherwise it would affect user experience w/o these fonts, and such rejects drive me bonkers every time.Is there any chance that Debian has kind of very similar fonts?
Maybe we can sneak in some fonts from shinydashboard (which appears similar) but it does not look straightforward, provided we are maintaining it longterm, it looks a bit difficult to manage with syncing up code from different packages so I am not very motivated to do something like this, unless it is the 'same' fonts.
Also, do you find anything else in the package that could be problematic?I admit I was very confused about the different versions of bootstrap (inst/lib/bs[345]). I f we want to replace these by the Debian packaged versions this might become a problem. No idea what inst/lib/bsw[345] might be. I'm very weak if it comes to understand all this JavaScript packages and maintaining different versions in one package sounds very scary to me since I'm afraid it could depend from specific minor version numbers and the package we distribute might be broken.
I think it would be possible to manage these with symlinking and patching a bit of the code We should be able to get this done, IMO. Could also ask upstream once for clarification. But this does not look like a turn off form the acceptance from NEW queue (which is the main bottleneck here) At this point, we _really_ need bslib since rmarkdown is lagging several versions behind.
Let me know about the above mentioned questions.Thanks again for working on this
Please consider helping me out with the above stuff :)
[1]: https://github.com/rstudio/bslib/issues/412 [2]: https://wiki.debian.org/DFSGLicenses#The_SIL_Open_Font_License
Regards, Nilesh
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature