Bug#996965: ITP: r-cran-bslib -- Custom 'Bootstrap' 'Sass' Themes for 'shiny' and 'rmarkdown'

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-bslib -- Custom 'Bootstrap' 'Sass' Themes for 'shiny' and 'rmarkdown'
Package: wnpp
Owner: Steffen Moeller <moe...@debian.org>
Severity: wishlist

* Package name : r-cran-bslib
Version : 0.3.1
Upstream Author : Carson Sievert,
* URL : https://cran.r-project.org/package=bslib
* License : MIT
Programming Lang: GNU R
Description : Custom 'Bootstrap' 'Sass' Themes for 'shiny' and 'rmarkdown'
Simplifies custom 'CSS' styling of both 'shiny' and 'rmarkdown' via
'Bootstrap' 'Sass'. Supports both 'Bootstrap' 3 and 4 as well as their
various 'Bootswatch' themes. An interactive widget is also provided for
previewing themes in real time.

Remark: This package is maintained by Debian R Packages Maintainers at
https://salsa.debian.org/r-pkg-team/r-cran-bslib

[Andreas Tille]

Hi Eric,

thanks a lot for your investigation. This is extremely helpful.

Am Tue, Apr 05, 2022 at 08:50:08PM -0400 schrieb Eric Brown:
> Hi again,
>
> I tried to see what happens when the woff files are deleted from bslib.
>
> I cloned the bslib git, deleted the contents of the font folder, built
> the R package locally, then tried to render an R markdown document
> that uses a bslib theme (minty).
> It fails with an error message (below).
>
> pandoc: /tmp/Rtmp1sYpTM/bslib-ca23be8b2c03436a7d75cedd4667b7ed/fonts/JTUSjIg1_i6t8kCHKm45xW0.woff:
> openBinaryFile: does not exist (No such file or directory)
> Error : pandoc document conversion failed with error 1
> Error: callr subprocess failed: pandoc document conversion failed with error 1
> Type .Last.error.trace to see where the error occurred

Seems we need the Montserrat font from texlive-fonts-extra. But there
are no *.woff files. Thus I guess we need to convert the proper font
from there to woff format - but I have no idea at all how to do this.

Kind regards

Andreas.

>
> Best,
> Eric
>
> On Tue, Apr 5, 2022 at 11:39 AM Eric Brown <e...@ericebrown.com> wrote:
> >
> > Hi Andreas,
> >
> > I can at least identify which .woff files correspond to which fonts,
> > that is possible with grep. Here's the output:
> > https://gist.github.com/eebrown/95615fc35af364bd0fae09a69273dbdf
> >
> > I think deleting the .woff files and seeing if the fonts render
> > properly when they are installed at the system level is reasonable but
> > I too am not sure exactly how to try out all the fonts.
> >
> > If that doesn't work, I guess it would be a matter of symlinking files
> > to replace the .woff files. This might require a step to derive the
> > .woff wiles in the format expected by bslib.
> >
> >
> > On Tue, Apr 5, 2022 at 9:44 AM Andreas Tille <and...@fam-tille.de> wrote:
> > >
> > > Hi Eric,
> > >
> > > Am Mon, Apr 04, 2022 at 06:42:59AM -0400 schrieb Eric Brown:
> > > > To update, I found that a few more are packaged in texlive-fonts-extra (
> > > > https://packages.debian.org/buster/texlive-fonts-extra)
> > > >
> > > > Roboto https://packages.debian.org/bullseye/fonts-roboto
> > > > Ubuntu https://packages.debian.org/bullseye/fonts-ubuntu
> > > > Open Sans https://packages.debian.org/sid/fonts-open-sans
> > > > Lato https://packages.debian.org/sid/fonts-lato
> > > > Cabin Sketch https://packages.debian.org/sid/fonts-cabinsketch
> > > > Montserrat, Nunito, Raleway, Source Sans Pro: texlive-fonts-extra
> > > >
> > > > This leaves 4 which I could not find in Debian:
> > > >
> > > > Nunito Sans https://github.com/googlefonts/NunitoSans
> > > > Inter https://github.com/rsms/inter/
> > > > News Cycle https://bazaar.launchpad.net/~n8/newscycle/
> > > > Neucha ?
> > >
> > > Thanks a lot for this very helpful investigation. The problem now is
> > > how to know which of the 60 inst/fonts/*.woff files we can remove from
> > > the source package since these are not needed and whether the fonts
> > > you said are found by bslib if we simply set the dependencies you
> > > mentioned above (and how to test this). The names of these *.woff
> > > files are absolutely cryptic and I need to admit I have no idea about
> > > all this fonts stuff.
> > >
> > > Kind regards
> > >
> > > Andreas.
> > >
> > > > Best,
> > > > Eric
> > > >
> > > > On Sun, Apr 3, 2022 at 14:34 Eric Brown <e...@ericebrown.com> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Since this is a pretty important package, I grep'd the package to see
> > > > > what fonts are included. It looks like some of them are already in
> > > > > Debian:
> > > > >
> > > > > Roboto https://packages.debian.org/bullseye/fonts-roboto
> > > > > Ubuntu https://packages.debian.org/bullseye/fonts-ubuntu
> > > > > Open Sans https://packages.debian.org/sid/fonts-open-sans
> > > > > Lato https://packages.debian.org/sid/fonts-lato
> > > > > Cabin Sketch https://packages.debian.org/sid/fonts-cabinsketch
> > > > >
> > > > > The rest are all SIL OFL licence (Debian compatible). I was able to find
> > > > > sources for all but two:
> > > > >
> > > > > Montserrat https://github.com/JulietaUla/Montserrat
> > > > > Nunito Sans https://github.com/googlefonts/NunitoSans
> > > > > Nunito https://github.com/googlefonts/nunito
> > > > > Inter https://github.com/rsms/inter/
> > > > > News Cycle https://bazaar.launchpad.net/~n8/newscycle/
> > > > > Raleway https://github.com/impallari/Raleway/
> > > > > Neucha ?
> > > > > Source Sans Pro ?
> > > > >
> > > > > Best,
> > > > > Eric
> > > > >
> > > > --
> > > > Eric Brown MD MSc FRCPC
> > > > For encryption, OpenPGP public key available on request.
> > >
> > > --
> > > http://fam-tille.de
> >
> >
> >
> > --
> > Eric Brown MD MSc FRCPC
> > For encryption, OpenPGP public key available on request.
>
>
>
> --
> Eric Brown MD MSc FRCPC
> For encryption, OpenPGP public key available on request.
>

--
http://fam-tille.de

[Andreas Tille]

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/rstudio/bslib/issues/412

[Nilesh Patra]

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

[Nilesh Patra]

Hi all,

[ CC'ed Andreas who last worked on this ]

bslib is needed for the new rmarkdown update, and it is being used in other packages
in the ecosystem as well, as it seems.

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 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?

Do you think upstream could do $something about this?

Admittedly, otherwise it would affect user experience w/o these fonts, and such rejects drive me
bonkers every time.

Also, do you find anything else in the package that could be problematic?

Let me know about the above mentioned questions.

[Andreas Tille]

Hi Nilesh,

Am Wed, Feb 23, 2022 at 12:24:41PM +0530 schrieb Nilesh Patra:

> bslib is needed for the new rmarkdown update, and it is being used in other packages
> in the ecosystem as well, as it seems.

Thanks a lot for working on this!

> 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.

> 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.

> 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.

> 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?

> 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.

> Let me know about the above mentioned questions.

Thanks again for working on this

Andreas.

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

--
http://fam-tille.de

[Andreas Tille]

Am Wed, Feb 23, 2022 at 01:52:26PM +0530 schrieb Nilesh Patra:
>
> This was what I was fearing.
> I need to admit that this is a 'gigantic' waste of everyone's time to be doing this.

Yes.

> 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 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.

> [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.

> 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?

> > 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.

> > 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.

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 ...

> 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).

> At this point, we _really_ need bslib since rmarkdown is lagging several versions behind.

I fully agree.

> > 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?

Kind regards

Andreas.

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

--
http://fam-tille.de

[Andreas Tille]

Hi,

Am Thu, Apr 14, 2022 at 11:26:58AM +0200 schrieb Andreas Tille:
> I did a next step in
>
> https://salsa.debian.org/r-pkg-team/r-cran-bslib/-/commit/7d066e14383753156d851e81b0db9e21665ce861
>
> where I simply try the patience of ftpmaster to accept binary fonts.
> I'll now try to sort out the licenses of the different bootstrap
> versions and hope to upload soon to new.

I've managed to exclude bootstrap3 but there are issues with the
Debian packaged bootstrap4 which I've reported upstream[1]. I'm now
checking what I can do for boostrap5 (besides removing it completely
for the moment and hoping that we can go with boostrap[34] as long
as version 5 is not packaged yet (I do not have a better idea right
now :-()

So far for the status of bslib

Andreas.

[1] https://github.com/rstudio/bslib/issues/422

--
http://fam-tille.de

[Andreas Tille]

Am Thu, Apr 14, 2022 at 07:51:05AM -0700 schrieb Carson Sievert:
> Sorry, but come of think of it, even if we do upgrade, it won't change the fact that we apply patches to the SCSS source code for BS4 and BS5 (to fix bugs and add features). Technically you'll probably be fine replacing `inst/lib/bs3` with whatever Debian bundles, but in generally this seems like a dangerous practice that could lead to surprising and difficult to debug regressions for end users (I hope you're not planning on doing the same for other HTML dependencies in shiny as we also applies patches to source there as well)

Thanks a lot for this hint. Do you see any chance to distribute the uncompressed source of the JS files? This would also help a lot.
Kind regards, Andreas.

[Andreas Tille]

Hi Eric,

Am Fri, Apr 15, 2022 at 02:44:11PM -0400 schrieb Eric Brown:
> It looks like conversion to .woff from .ttf or .otf is straightforward
> with woff-tools, e.g. install fonts-roboto, then the appropriate file
> can be converted by, e.g. `sfnt2woff Roboto-Regular.ttf` which creates
> Roboto-Regular.woff.
>
> I also found that fonts-inter is in Debian. So it appears only 3 fonts
> would need to be packaged. I've opened RFP bugs for them:

I agree that the conversion to woff format is possible. I've managed
this myself last week. The reason why I did not reported this here and
rather decided to simply try uploading the fonts as they are is, that I
have no idea how to find out a relation between those fonts and the
cryptic (random???) font files names that are used in bslib. So even if
we could convert existing font files - how should we maintain these
conversions to move them to the file names that are obviously used
inside the css files?

> Nunito Sans https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009730
> Neucha https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009729
> News Cycle https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009707

Thanks a lot for your investigation which is extremely welcome.

Kind regards
Andreas.

>
> On Wed, Apr 13, 2022 at 1:56 PM Eric Brown <e...@ericebrown.com> wrote:
> >
> > Minor update with source:
> >
> > In Debian:

> >
> > Roboto https://packages.debian.org/bullseye/fonts-roboto
> > Ubuntu https://packages.debian.org/bullseye/fonts-ubuntu
> > Open Sans https://packages.debian.org/sid/fonts-open-sans
> > Lato https://packages.debian.org/sid/fonts-lato
> > Cabin Sketch https://packages.debian.org/sid/fonts-cabinsketch
> >

> > In Debian but should ideally be packaged separately due to large size
> > of texlive-fonts-extra and current policy:

> >
> > Montserrat, Nunito, Raleway, Source Sans Pro: texlive-fonts-extra
> >

> > Need Debian package (all have open licences):

> >
> > Nunito Sans https://github.com/googlefonts/NunitoSans
> > Inter https://github.com/rsms/inter/

> > News Cycle https://launchpad.net/newscycle
> > Neucha https://typetype.org/wp-content/uploads/neucha.zip

[Andreas Tille]

Hi,

Am Wed, Apr 20, 2022 at 11:13:07PM +0530 schrieb Nilesh Patra:
> On Fri, Apr 15, 2022 at 01:24:31PM -0400, Eric Brown wrote:
> > I have gone ahead and opened RFP bugs for the fonts which are not in Debian
> > but needed by r-cran-bslib (referred to by Nilesh above).
>
> Thank you very much for finding me and tracking me here.

>
> > Nunito Sans https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009730
> > Neucha https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009729
> > News Cycle https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009707
>

> Great.
> However, I am on a (sort of) VAC these days and wouldn't have time to package
> these soonish.
> @Andreas, could you start with one if you have free cycles?

My grandchildren are here until Sunday - so no for this week.

Meanwhile I would love to have any clue how we can associate the Debian
font with the absolutely cryptic bslib font name. My current strategy
is to rather try with the upstream fonts and see what ftpmaster might
think about this since even if we have the fonts I have no idea what to
do after we have converted these to woff format.

Kind regards

Andreas.

--
http://fam-tille.de

[Nilesh Patra]

On Wed, Apr 20, 2022 at 08:57:15PM +0200, Andreas Tille wrote:
> > Great.
> > However, I am on a (sort of) VAC these days and wouldn't have time to package
> > these soonish.
> > @Andreas, could you start with one if you have free cycles?
>
> My grandchildren are here until Sunday - so no for this week.

Sure - looks like we are all busy :)

> Meanwhile I would love to have any clue how we can associate the Debian
> font with the absolutely cryptic bslib font name. My current strategy
> is to rather try with the upstream fonts and see what ftpmaster might

> think about this [...]

If you want to check ftp master's views, please uploade sooner (than later)

Regards, Nilesh

[Andreas Tille]

Am Thu, Apr 21, 2022 at 12:32:29AM +0530 schrieb Nilesh Patra:
> If you want to check ftp master's views, please uploade sooner (than later)

Its ready except for bs5. I'm tempted to remove this functionality (at the
beginning of next week if nobody beats me).

[Andreas Tille]

Hi again,

I've made some progress with bslib but now I have trouble with its
autopkgtest. Bslib provides different versions of bootstrap (version 3,
4 and 5) to provide a unique interface for all R packages. I managed
that the provided unittests are working for bootstrap4 but it fails for
some tests of bootstrap3. This is true for the original bootstrap3
as distributed by Debian as well as the patched version (bslib contains
a set of patches which I applied in the process of packaging). The
erroneous code is not affected by the patch. Here is an example for
the failure:

── Error (test-theme-base-colors.R:45:3): bs3 base colors ──────────────────────
Error in `compile_data(sass_input, options)`: Error: Invalid CSS after "... floor(math": expected expression (e.g. 1px, bold), was ".div($grid-gutter-w"
on line 369:46 of ../../../../../../usr/share/nodejs/bootstrap-sass/assets/stylesheets/bootstrap/_variables.scss
from line 110:1 of stdin
>> vbar-padding-horizontal: floor(math.div($grid-gutter-width, 2)) !defa
------------------------------------------^
Backtrace:
▆
1. └─bslib::bs_get_variables(theme, varnames) at test-theme-base-colors.R:45:2
2. └─sass::sass_partial(...)
3. └─sass::sass(...)
4. └─sass:::compile_data(sass_input, options)
── Error (test-theme-base-colors.R:106:3): bs3 accent colors ───────────────────

This is from the patched code - the full autopkgtest log is here:

https://salsa.debian.org/r-pkg-team/r-cran-bslib/-/jobs/2706701#L1056

If the bslib patches are not applied the autopkgtest log looks like

https://salsa.debian.org/r-pkg-team/r-cran-bslib/-/jobs/2700112#L1056

Any hint how to fix the css code would be really helpful.

Kind regards

Andreas.

--
http://fam-tille.de

[Nilesh Patra]

On Wed, Apr 27, 2022 at 10:59:25AM +0200, Andreas Tille wrote:
> ── Error (test-theme-base-colors.R:45:3): bs3 base colors ──────────────────────
> Error in `compile_data(sass_input, options)`: Error: Invalid CSS after "... floor(math": expected expression (e.g. 1px, bold), was ".div($grid-gutter-w"
> on line 369:46 of ../../../../../../usr/share/nodejs/bootstrap-sass/assets/stylesheets/bootstrap/_variables.scss

This was coming from node-bootstrap-sass directly as it was using new API for some
functions which is not yet compatible with sass.
I have fixed them. Now, 200 tests pass and just a couple of tests fail and I am out of
time to check those now. _maybe_ you could skip for now and upload to unstable (which is high prio)

BTW please repack all the minified files and minify them during the build using terser[1] or something similar

[1]: https://tracker.debian.org/pkg/node-terser

Regards
Nilesh

[Andreas Tille]

Hi Nilesh,

Am Wed, Apr 27, 2022 at 04:30:40PM +0530 schrieb Nilesh Patra:
> On Wed, Apr 27, 2022 at 10:59:25AM +0200, Andreas Tille wrote:
> > ── Error (test-theme-base-colors.R:45:3): bs3 base colors ──────────────────────
> > Error in `compile_data(sass_input, options)`: Error: Invalid CSS after "... floor(math": expected expression (e.g. 1px, bold), was ".div($grid-gutter-w"
> > on line 369:46 of ../../../../../../usr/share/nodejs/bootstrap-sass/assets/stylesheets/bootstrap/_variables.scss
>
> This was coming from node-bootstrap-sass directly as it was using new API for some
> functions which is not yet compatible with sass.
> I have fixed them. Now, 200 tests pass and just a couple of tests fail and I am out of
> time to check those now. _maybe_ you could skip for now and upload to unstable (which is high prio)

Thanks a lot for your help on this (deserves another $drink from me ;-) )
Those three failing tests are patched out now.

> BTW please repack all the minified files and minify them during the build using terser[1] or something similar

I tried to repack[2] but I get

r-cran-bslib/debian/missing_source/bs5(master) $ terser --compress --mangle -- bootstrap.bundle.js

/usr/share/nodejs/terser/bin/terser:153
if (~opts.rawArgs.indexOf("--rename")) {
^
TypeError: Cannot read property 'indexOf' of undefined
at Object.<anonymous> (/usr/share/nodejs/terser/bin/terser:153:19)
at Module._compile (internal/modules/cjs/loader.js:1085:14)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)
at Module.load (internal/modules/cjs/loader.js:950:32)
at Function.Module._load (internal/modules/cjs/loader.js:790:12)
at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:75:12)
at internal/main/run_main_module.js:17:47

/usr/share/nodejs/terser/tools/exit.js:14
throw exit;
^
[Function: exit]


Any idea what might be wrong?

Kind regards

Andreas.

> [1]: https://tracker.debian.org/pkg/node-terser

[2] https://salsa.debian.org/r-pkg-team/r-cran-bslib/-/tree/master/debian/missing_source/bs5

--
http://fam-tille.de

[Nilesh Patra]

On Wed, Apr 27, 2022 at 03:22:59PM +0200, Andreas Tille wrote:
> Thanks a lot for your help on this (deserves another $drink from me ;-) )

This count is increasing with each passing day :)

> Those three failing tests are patched out now.

Fine

> > BTW please repack all the minified files and minify them during the build using terser[1] or something similar
>
> I tried to repack[2] but I get
>
> r-cran-bslib/debian/missing_source/bs5(master) $ terser --compress --mangle -- bootstrap.bundle.js
>
> /usr/share/nodejs/terser/bin/terser:153
> if (~opts.rawArgs.indexOf("--rename")) {
^

Um, weird.
It works fine for me (checked on a clean system in a chroot), are you using terser provided by "uglifyjs.terser"?
Can you try running

$ terser --compress --mangle -o bootstrap.bundle.min.js bootstrap.bundle.js
$ ls
bootstrap.bundle.js bootstrap.bundle.min.js get

Alternatively, you can also use uglifyjs[3]

> > [1]: https://tracker.debian.org/pkg/node-terser
> [2] https://salsa.debian.org/r-pkg-team/r-cran-bslib/-/tree/master/debian/missing_source/bs5

[3]: https://tracker.debian.org/pkg/uglifyjs

Regards
Nilesh

[Andreas Tille]

Hi Nilesh,

Am Wed, Apr 27, 2022 at 07:26:04PM +0530 schrieb Nilesh Patra:
> > Thanks a lot for your help on this (deserves another $drink from me ;-) )
>
> This count is increasing with each passing day :)

Just giving honor to those whom deserve honor. ;-)

> > I tried to repack[2] but I get
> >
> > r-cran-bslib/debian/missing_source/bs5(master) $ terser --compress --mangle -- bootstrap.bundle.js
> >
> > /usr/share/nodejs/terser/bin/terser:153
> > if (~opts.rawArgs.indexOf("--rename")) {
> ^
>
> Um, weird.
> It works fine for me (checked on a clean system in a chroot), are you using terser provided by "uglifyjs.terser"?

No, just terser from unstable. It works now with uglifyjs.terser (as
per my last commit). How can I recreate bootstrap.bundle.min.js.map ?

[Nilesh Patra]

On 27 April 2022 7:41:40 pm IST, Andreas Tille <ti...@debian.org> wrote:
>> Um, weird.
>> It works fine for me (checked on a clean system in a chroot), are you using terser provided by "uglifyjs.terser"?
>
>No, just terser from unstable.

Then maybe you have an older copy. Terser is a virtual package now.

> It works now with uglifyjs.terser (as
>per my last commit). How can I recreate bootstrap.bundle.min.js.map ?

There should be a source-map option or something similar, you could check the manpage/examples once.


Regards,
Nilesh