nxadm / rakudo-pkg

Pre-compiled OS packages for Rakudo
GNU General Public License v3.0
71 stars 22 forks source link

SRPM's #58

Closed ToddAndMargo closed 4 years ago

ToddAndMargo commented 4 years ago

Would you please post the SRPM for

https://github.com/nxadm/rakudo-pkg/releases/download/v2019.07.1-03/rakudo-pkg-Fedora31-2019.07.1-03.x86_64.rpm

nxadm commented 4 years ago

Hi @ToddAndMargo,

The packages are built with fpm. By default fpm does not use external spec files. No srpm files are generated.

The buildlog with the exact fpm command can be found here.

tbrowder commented 4 years ago

Todd is having trouble with accessing his modules with a simple Perl 6 (Raku) one-liner. I have no problems on my Debian 10 Linux system with his test files, but he does. I am installing from a source release and he is not. It seems to be an FC package problem starting with FC 31. Any debugging help would be appreciated.

nxadm commented 4 years ago

I don't understand the issue completely. Is Todd using the Fedora 31 repo of rakudo-pkg or a different package (e.g. the one from Fedora itself)? Do their modules work with the rakudo-pkg rpm?

tbrowder commented 4 years ago

I'm not sure, but I think they are yours. I'll try to get him to tell you.

nxadm commented 4 years ago

@tbrowder @ToddAndMargo I will be more than happy to help with the debugging.

ToddAndMargo commented 4 years ago

Hi Tbrowder,

The issue is only reproducible under Fedora 31.

The rpm's I have tried are the stock ones that come from the Fedora repo (annoying that they separate zef) and the ones from your web site located at

https://github.com/nxadm/rakudo-pkg/releases

I have tested the following from your web site and the issue repeats with all of them

rakudo-pkg-Fedora29-2018.11-01.x86_64.rpm rakudo-pkg-Fedora29-2019.03.1-01.x86_64.rpm rakudo-pkg-Fedora30-2019.03.1-03.x86_64.rpm rakudo-pkg-Fedora30-2019.07.1-03.x86_64.rpm rakudo-pkg-Fedora31-2019.07.1-03.x86_64.rpm

Please keep in mind that this issue only manifests itself under Fedora 31. There is no such issue under Fedora 30 and rakudo-pkg-Fedora30-2019.07.1-03.x86_64.rpm, which is what I was running before upgrading to Fedora 31.

I also tested under a clean Fedora 31 qemy-kvm virtual machine what had never before been touched by Perl 6 and the problem reproduced itself.

At this point, I would guess you would want to know what the issue is:

I run my Perl programs (5 and 6) out of /home/linuxutil. I place my custom Perl 6 modules, which I do not want to share with the world or other users, into a directory called p6lib (name does not matter to reproduce this). When I run my programs, all modules installed by zef are found, but my custom modules care read (and a .precomp created), but the exported subs can not be found. Well, depending on the position of the moon overhead, they are not found 97% of the time.

The problem reproduces with SELinux on or off.

And let me emphasize, ONLY on Fedora 31.

An actual program, the error looks like this: $ GetPublicIP.pl6 ===SORRY!=== Error while compiling /home/linuxutil/./GetPublicIP.pl6 Undeclared names: RunNoShell used at lines 19, 23 WriteSecondaryClipboard used at line 24

I usually can reproduce the issue with <p6lib/ModuleTest.pm6> sub ModuleTest() is export( :ModuleTest ) { say "Hi"; } sub ModuleTst() is export( :ModuleTst ) { say "Bye"; } </p6lib/ModuleTest.pm6>

and

#!/usr/bin/env perl6 use lib '/home/linuxutil/p6lib'; use ModuleTest :ModuleTest, :ModuleTst; ModuleTest; ModuleTst; But the moon must be just right, because not right now. GetPublicIP.pl6 worked once when I logged in today, but not any more. It is back to "Undeclared names" This is the code for GetPublicIP.pl6: #!/usr/bin/env perl6 use lib '/home/linuxutil/p6lib'; use RunNoShellLib; # qw[ RunNoShell RunNoShellCode RunNoShellErr ] use X11Clipboard; # qw[ WritePrimaryClipboard WriteSecondaryClipboard ReadPrimaryClipboard ReadSecondaryClipboard ] use CheckSystemDependancy; # qw [ Which CheckSysDependancy ]; my $DigRtnCode; my $PublicIP; my $InfoPng = "/home/linuxutil/Images/Info.png"; ( my $IAm = $?FILE ) ~~ s|.*"/"||; CheckSysDependancy( "xsel", "die" ); CheckSysDependancy( "notify-send", "die" ); CheckSysDependancy( "dig", "die" ); ( $PublicIP, $DigRtnCode ) = RunNoShell( "dig +short myip.opendns.com \@resolver1.opendns.com" ); chomp( $PublicIP ); print "$PublicIP\n"; RunNoShell( "notify-send -u normal -t 10000 -i \"$InfoPng\" \"$IAm\" \"$PublicIP\nPasted to the Clipboard\"" ); WriteSecondaryClipboard ( $PublicIP );
ToddAndMargo commented 4 years ago

Hi @ToddAndMargo,

The packages are built with fpm. By default fpm does not use external spec files. No srpm files are generated.

The buildlog with the exact fpm command can be found here.

Companion bug:

RFE: please use github's Perl 6 release https://bugzilla.redhat.com/show_bug.cgi?id=1531856

ToddAndMargo commented 4 years ago

The original intent of this bug was to get Fedora to use you superior RPMs in their repo. Their rules are that they won't include anything without a SRPM. Maybe they will take your fpm?

Follow up on the other problem:

Fedora 31 became hard nosed about my mistakes. Tom on the Perl 6 mailing list called it.

I had thought all my modules used "unit module MyModule;", but into everyone life a little humility must fall, not all of them were. They are now.

And everyone that imported things suddenly demanded I use :some-key nicknames, which makes my code a lot easier to maintain.

Why Fedora 30 let me get away with such hell is a mystery.

Lets hope my modules still like the position of the moon when it goes down!

You know, when it is your problem, it is better because it is something you can fix. The egg on the face thing is another issue. Thank you all for the generous help.

Everything is behaving now. Thank you! -T

tbrowder commented 4 years ago

On Tue, Nov 5, 2019 at 1:42 AM ToddAndMargo notifications@github.com wrote:

Follow up: ...

Everything is behaving now. Thank you!

Glad it all works now, Todd!

Blessings!

-Tom

P.S. I love Raku (Perl 6)!

nxadm commented 4 years ago

Great to hear the problem is fixed.

About SRPM. I agree with Fedora here that they need to build their packages from SPEC files. They are building a complete repository, with possible and likely conflict between packages. They have an infrastructure and best practices to deal with it.

By design, rakudo-pkg is isolated in /opt/rakudo-pkg and does not interfere with system packages. The advantage of this is that I can take a shortcut for creating the package, because it does not have to take hypothetical conflicts in consideration (e.g. 2 rakudo binaries in /usr/bin).

Fedora goes for system integration and I go for closely following upstream and system isolation. Both packages have their place.

ToddAndMargo commented 4 years ago

Considering the trouble I went through with Fedora 31 and the fact I could not reproduce on Fedora 30 and other could also not reproduce, would you consider adding "unit module MyModule;" as a compiler error (perl6 -c) for all modules encountered?

nxadm commented 4 years ago

@ToddAndMargo,

I think that bug report (or PR) should go to https://github.com/perl6/roast or https://github.com/rakudo/rakudo/.

ToddAndMargo commented 4 years ago

Reported at

treyharris commented 4 years ago

Reported at

Reported at? Was that missing a link?

ToddAndMargo commented 4 years ago

Huh. It was there yesterday. Here it is again in plain text:

https://github.com/rakudo/rakudo/issues/3296

nxadm commented 4 years ago

Thanks, everyone. I will close this ticket because it will be handled upstream.