|
00:12
kjp left
00:14
kjp joined
00:15
kjp left,
kjp joined
07:20
Guest50 joined
07:21
Guest50 left
08:24
sp1983 joined
08:49
sp1983 left
12:21
Pixi left
12:36
Pixi joined
15:19
sp1983 joined
|
|||
| sp1983 | o/ | 15:20 | |
| there is error when building Hash::Merge against Rakudo 2026.03 in aarch64 - lang-call cannot invoke object of type 'VMNull' belonging to no language | |||
| at /builddir/build/BUILD/raku-hash-merge-2.0.0/vendor#sources/3A740CC2EDEBFDBE342C298E66C87C9E3533CDFA (Hash::Merge::Augment):6 | |||
| does it ring any bell to any one ? | 15:21 | ||
| here is full log - download.copr.fedorainfracloud.org...ive.log.gz | |||
| ^^ El_Che: | |||
| lizmat | builds ok on MacOS | 15:22 | |
| fwiw | |||
|
15:26
sp1983 left
15:28
sp1983 joined
|
|||
| sp1983 | yeah, same for me | 15:28 | |
| disbot2 | <melezhik.> Probably need to build against fresh aarch64 binary myself | 15:36 | |
| lizmat | is it repeatable, or a flapper ? | 15:39 | |
| sp1983 | sorry, for confusion it happens on x86_64 | 15:44 | |
| looks like a flapper | 15:45 | ||
| based on "I've tried building in a couple of different ways, and under some conditions it does not complain.." | 15:46 | ||
|
15:56
sp1983 left
16:00
sp1983 joined
|
|||
| sp1983 | or better say environment dependent | 16:01 | |
|
16:02
grayeul joined
16:08
sp1983 left,
sp1983 joined
16:12
sp1983 left
19:09
[Coke] left
21:05
[Coke] joined
|
|||
| grayeul | So ... I have a sort of packaging question... I'm not very familiar with raku usage, but I've been asked to put together some rocky-linux rpm packages to provide a controlled set of rakudo baseline packages. | 22:18 | |
| lizmat | El_Che patrickb timo ^^ | 22:20 | |
| grayeul | I'm trying to install (using install-dist.raku) a few different packages (individually -- each into their own rpm). What I'm seeing is that two different packages are 'fighting' over the same precomp files. So, I'm trying to understand why when I install (e.g.) Terminal::ANSIColor I get some of the same files as when I install JSON::Fast | ||
| For example: hare/perl6/vendor/.precomp/CD2858E4B48D26E12AB7903CDD61A7201262E08D/4C/4C8907699141DCFF1B0B1A3B6A4D49D076402168.repo-id | 22:21 | ||
| I don't know how to tell what generates that particular file, and why it would appear in two different packages. -- any help appreciated... | |||
| I also have a different problem (mentioned earlier) .. when trying to build the Hash::Merge into an rpm. I think the problem relates to the fact that I'm installing into a non-standard location (within a /buildroot) that won't be where the module appears in the end... but it seems during the 'prep' of the Hash::Merge package, in the Hash::Merge:Augment area, there is a 'use Hash::Merge' -- and I think | 22:24 | ||
| it is not finding that, as I'm still trying to install it (and it isn't in an expected place). | |||
| I tried setting RAKUDOLIB to add the path I'm putting things, but that didn't seem to help... I *think* that just adds to the standard path, right? I don't have to list all possible paths if I do set RAKUDOLIB | 22:25 | ||
| timo | salsa.debian.org/perl6-team/dh-rak...type=heads steal from how debian builds the modules, or how they are built for opensuse: build.opensuse.org/projects/devel:...c?expand=1 | 22:55 | |
| the RAKUDO_RERESOLVE_DEPENDENCIES=0 might be relevant | |||
| grayeul | I did have that set to 0 | 23:19 | |
| timo | OK, with RAKUDO_MODULE_DEBUG you should see mentions of the files that conflict and that should help see where it comes from | 23:22 | |
| grayeul | I'll try that... but there is no conflict when I build pkg A, or pkg B separetely -- it is at install time that 'rpm' complains two different packages are trying to provide the same file. | 23:26 | |
| Is the .precomp directory needed? Looks like that's where the conflicts are... | 23:30 | ||
| timo | I've encountered issues when doing debian packaging where a not-tight-enough dependency version specification caused the package with the dependency to separately precompile the dependent package even though it should have taken the existing one because the version from the specification didn't match the version of the dependent package in a check somewhere | 23:35 | |
| maybe that's what's happening to you, but I don't think Terminal::ANSIColor has any dependencies, and I know that JSON::Fast doesn't | |||
| so the only thing it might be depending on and causing a re-precompile of could be parts of rakudo itself | 23:36 | ||
| I was able to figure that out from the RAKUDO_MODULE_DEBUG output | |||
| grayeul | yeah, there shouldn't be any real dependencies in play, I don't think... that's why it is odd -- | 23:57 | |