On വ്യാ, ജൂൺ 2 2022 at 08:58:37 വൈകു -03:00:00
-03:00:00, Antonio Terceiro <terce...@debian.org> wrote:
On Thu, Jun 02, 2022 at 06:03:47PM -0300, Lucas Kanashiro wrote:
Em 01/06/2022 15:42, Pirate Praveen escreveu:
> On Sun, 13 Feb 2022 08:59:18 +0100 Lucas Nussbaum
<lu...@debian.org>
> wrote:
> > During a rebuild of all packages in sid, your package failed to
build
> > on amd64.
> >
> >
> > Relevant part (hopefully):
> > > make[1]: Entering directory '/<<PKGBUILDDIR>>'
> > > mkdir -p vendor/assets/javascripts
> > > ln -s /usr/share/javascript/handlebars/handlebars.js
> vendor/assets/javascripts/handlebars.js
> > > ln -s
> /usr/share/javascript/handlebars.runtime/handlebars.runtime.js
> vendor/assets/javascripts/handlebars.runtime.js
>
> [...]
>
> > > Failed to load /dev/null because it doesn't contain valid
YAML hash
> > > ERROR: While executing gem ... (Gem::Package::SymlinkError)
> > > installing symlink
'vendor/assets/javascripts/handlebars.js'
> pointing to parent path
/usr/share/javascript/handlebars/handlebars.js
> of
>
/<<PKGBUILDDIR>>/debian/ruby-handlebars-assets/usr/share/rubygems-integration/all/gems/handlebars_assets-0.23.8
> is not allowed
>
> How do we handle this issue? Should we copy instead? If that is
the
> solution, we will have to rebuild ruby package whenever the js
package
> changes. Can we modify rubygems to allow this link?
Can you try creating the symlink *after* rubygems has done its thing?
i.e. instead of creating the link in the source tree, create it at the
installation directory, after the installation has been done.
We won't be able to run the tests. If I comment out the ln commands,
tests fail with
Errno::ENOENT: No such file or directory @ rb_sysopen -
vendor/assets/javascripts/handlebars.js
May be we can copy during build and replace it by symlink in install?
I believe this behavior was introduced by this rubygems upstream
commit:
https://github.com/rubygems/rubygems/commit/555692b8deb8f6b27ce29b843dc59384d508e8c1
One thing we could try is to revert it, but maybe we should try to
create a good and convincing user story to file an upstream bug and
get
it fixed there.
This could be a flag to disable this check that gem2deb could use. I
don't know if that's simpler than working around the issue as I
suggest
above (not tested, so not sure it works yet).
