Fail to build/run: Missing files from `foliate-js`

[highvoltage]

Hi

While attempting to build version 3.0.0 for Debian, I get the following error:

[1/26] /usr/bin/glib-compile-resources ../src/gresource.xml --sourcedir ../src --internal --generate --target src/com.github.johnfactotum.Foliate.gresource --dependency-file src/com.github.johnfactotum.Foliate.gresource.d
FAILED: src/com.github.johnfactotum.Foliate.gresource 
/usr/bin/glib-compile-resources ../src/gresource.xml --sourcedir ../src --internal --generate --target src/com.github.johnfactotum.Foliate.gresource --dependency-file src/com.github.johnfactotum.Foliate.gresource.d
../src/gresource.xml: Failed to locate “foliate-js/comic-book.js” in any source directory.

Although comic-book.js doesn't seem present anywhere in the source?

Any advice?

thanks,

-Jonathan

[brezanac]

You need to provide--recurse-submodules as an argument to git clone in order to pull all the submodules which serve as dependencies to the project.

git clone --recurse-submodules https://github.com/johnfactotum/foliate.git

The missing file (comic-book.js) is part of the foliate-js project which serves as a git submodule dependency to this project.

[alerque]

It would be useful if this project provided a source dist tarball.

[highvoltage]

It would be useful if this project provided a source dist tarball.

They do, but they don't include that in there. I think they do the right thing by not including it, but they should list foliate-js as a dependency then and include it in the build instructions.

[alerque]

No they don't. The only tarballs I've seen are the auto generated git archive ones that of course only include the repo contents. A source dist tarball is different and absolutely should include all vendored code from submodules. If submodules is the way the project pins build time source dependencies then a source dist would of course include them. I'm sure meson has a command for generating this because it is standard procedure.

The alternative would be to release versioned (i.e. tagged stable releases) of the dependency as a stand alone project that would be built and installed separately to the system (or in the case of distros like I'm packaging for, packaged and distributed), but that project layout doesn't seem to make sense in this case.

[johnfactotum]

Yeah. I'm not against providing a tarball, but it seems pretty pointless to me when

• You can't stop GitHub from providing broken downloads
• You can't stop people from forgetting to clone the submodules
• There should be a single source of truth as to what a release contains, which should be the tagged git commit
• People can easily build their own tarballs if they really need it

That said, I would accept a PR for using GitHub Actions to create tarballs. That way it would at least be more or less reproducible rather than something that I have to create manually.

[alerque]

https://mesonbuild.com/Creating-releases.html

The GitHub tarballs aren't "broken", they are what they are. They just are not source releases, they are repo archives. You can't stop people from downloading them but if the right thing is available attached to releases my experience is most people figure it out from there. When there is no source dist attached then people turn to the git archive or clone and get into trouble.

[alerque]

I just tested and meson dist does work with this project as-is to generate a source release.

[highvoltage]

From the Debian packaging side, I just need a tarball that I can build a package from that's suitable for distribution. So some feedback from me: generating a source release would be very useful and beneficial. Thanks!

[johnfactotum]

Very well. I guess I will add it. Still I don't understand why distro's can't just use git as the source 🤷️

[alerque]

Some can. But one reason some can't / won't is that they keep copies or original sources and it is a lot easier to keep a copy of a tar file than an entire Git repository with history. When you're working with distributed build systems, reproducibility testing bots, etc. it makes sense to have encapsulated sources. There are ways to do it with Git, but not all distros are plumbed that way and sometimes even when they are it is just preferable to use an easily checksummed single file.

[johnfactotum]

Fixed.

[highvoltage]

Sure it's fixed, I still have it on 3.0.1

$ /usr/bin/glib-compile-resources ../src/gresource.xml --sourcedir ../src --internal --generate --target src/com.github.johnfactotum.Foliate.gresource --dependency-file src/com.github.johnfactotum.Foliate.gresource.d
../src/gresource.xml: Failed to locate “foliate-js/comic-book.js” in any source directory.

[highvoltage]

Ah! I see I need to switch to com.github.johnfactotum.Foliate-3.0.1.tar.xz - will do!