[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packaging bslib + licensing issues




On 23.02.22 14:41, Nilesh Patra wrote:

On 23 February 2022 6:39:57 pm IST, Andreas Tille <andreas@an3as.eu> wrote:
Am Wed, Feb 23, 2022 at 01:52:26PM +0530 schrieb Nilesh Patra:
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'd rephrase "looks *very* unlikely" to "will never happen".

Its simply since we gave ourself rules and we asked people to stick to
those rules letter by letter.
I really feel like proposing a GR right away, so we get above these hard bound rules and * actually * work on user experience

I would second this.

I am not sure if I want to compromise for packages that are essential
since this may be interpreted as not-substitutable. But everything
transient like our R packages or whatever else fixes something in our
Real Lifes Debian should have a less extremist stance.

The problem is not only that we cannot package/redistribute it. My
problem is that we cannot grow towards true Freeness together with
upstream with subsequent updates.

Steffen


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?
Well, in the past I tried this "quickly check via <some medium>" but I
*never* got any answer.  It only works by simply trying via new queue.
I'd recommend trying the way that creates less work and than we'll see.
Alright, after some discussion and asking the upstream when both you and I can agree, we will dput and see what entails

[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.
That's a shame.  In the past I tried one or two font packages where I
was more lucky.
Can't do much about this, to be fair; this is just luck here

Additionally, can you address your findings on the github issue please?
That'd help track things smoothly.
You mean to ask upstream in issue #412 to include sources and clarify
why 3 versions of bootstrap are needed?
All your findings/questions:

* Why are three versions of bootstrap needed?
* Is it possible to provide sources for font binaries?
* If not, can you adapt to the ones that are in debian?
* Are there more fallbacks that you could introduce
* Is it possible to simplify licensing for binaries?

..... So on


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.
I can perfectly understand that such issues are draining from
motivation (guess why I procrastinated).  But may be upstream
can be convinced to use some more default fonts - its not that
Debian would include a small set of fonts.
Yes, I also was thinking about it and addressed it above

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.
The problem I see is that while patching might be possible its hard to
find out where patching is needed.  Finally we are talking about some
GUI we can hardly test automatically and so we never really know whether
something is broken or not.  My experience on user behaviour is that
in case of such problems they will simply move on with something else
and will not report - so we will never know ...
As long as there's no hard dependency on the versions of those files, we should be fine. But only upstream can clarify

But this does not look like a turn off form the acceptance from NEW queue (which is the main bottleneck here)
I agree that this might be not a bottleneck - except that we possibly
do not have all three bootstrap versions (at least not when I checked
last time, thought).
We only have one version in the archive at given point in time.

Thanks again for working on this
Please consider helping me out with the above stuff :)
So you want me to get involved into [1], right?
Right.

Regards,
Nilesh

[1]: https://github.com/rstudio/bslib/issues/412
[2]:  https://wiki.debian.org/DFSGLicenses#The_SIL_Open_Font_License



Reply to: