Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 617640 - media-gfx/slic3r-9999 patch fails again
Summary: media-gfx/slic3r-9999 patch fails again
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: 3D Printing Team
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks:
 
Reported: 2017-05-06 11:47 UTC by Philipp Psurek
Modified: 2018-06-06 13:22 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
slic3r-9999-adjust_var_path.patch (slic3r-9999-adjust_var_path.patch,387 bytes, patch)
2017-05-06 11:47 UTC, Philipp Psurek
Details | Diff
slic3r-9999.ebuild (slic3r-9999.ebuild,2.51 KB, text/plain)
2017-05-06 12:00 UTC, Philipp Psurek
Details
slic3r-9999.ebuild (slic3r-9999.ebuild,2.55 KB, text/plain)
2017-05-06 20:08 UTC, Philipp Psurek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Philipp Psurek 2017-05-06 11:47:59 UTC
Created attachment 471806 [details, diff]
slic3r-9999-adjust_var_path.patch

Patch fails again. This one works:

slic3r-9999-adjust_var_path.patch

--- a/lib/Slic3r.pm	2016-12-18 15:24:37.520000000 +0100
+++ b/lib/Slic3r.pm	2016-12-18 15:25:23.430000000 +0100
@@ -42,7 +42,7 @@
 
 use FindBin;
 # Path to the images.
-my $varpath = decode_path($FindBin::Bin) . "/var";
+my $varpath = decode_path($FindBin::RealBin) . "/var";
 if ($^O eq 'darwin' && !-d $varpath) {
     $varpath = decode_path($FindBin::Bin) . "/../Resources/var";
 }
Comment 1 Philipp Psurek 2017-05-06 12:00:00 UTC
Created attachment 471808 [details]
slic3r-9999.ebuild

I suggest to skip the patching and realise the change with sed:
  sed -i lib/Slic3r.pm -e "s@FindBin::Bin@FindBin::RealBin@g" || die
works fine
Comment 2 Amy Liffey gentoo-dev 2017-05-06 15:12:12 UTC
commit 6443f68173b24e1901d133757f5a369f821fc2eb
Author: Amy Liffey <amynka@gentoo.org>
Date:   Sat May 6 16:42:37 2017 +0200

    media-gfx/slic3r: fix patching bug #617640
    
    Submitted-by: Philipp Psurek <philipp.psurek+gentoo@gmail.com>
    Package-Manager: portage-2.3.3
Comment 3 Philipp Psurek 2017-05-06 20:08:45 UTC
Created attachment 471832 [details]
slic3r-9999.ebuild

sorry for the inconvenience but I didn't check the correct behaviour of slic3r. I see now that slic3r won't start:

"
Can't locate local/lib.pm in @INC (you may need to install the local::lib module) (@INC contains: /usr/bin/lib /etc/perl /usr/local/lib64/perl5/5.24.1/x86_64-linux-thread-multi /usr/local/lib64/perl5/5.24.1 /usr/lib64/perl5/vendor_perl/5.24.1/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.24.1 /usr/local/lib64/perl5 /usr/lib64/perl5/vendor_perl /usr/lib64/perl5/5.24.1/x86_64-linux-thread-multi /usr/lib64/perl5/5.24.1 .) at /usr/bin/slic3r.pl line 9.
BEGIN failed--compilation aborted at /usr/bin/slic3r.pl line 9.
"

There has to be one more change in slic3r.pl:
-    use local::lib '--no-create', "$FindBin::Bin/local-lib";
+    use lib '--no-create', "$FindBin::Bin/local-lib";

This change is now done by the attached ebuild. May somebody who speaks Perl look over this change and tell if this doesn't break anything. I've compiled slic3r with provided ebuild and it seems to run so far without errors.

slic3r-9999-adjust_var_path.patch in ${FILESDIR} can be removed.
Comment 4 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2017-05-06 23:26:37 UTC
(In reply to Philipp Psurek from comment #3)
> 
> There has to be one more change in slic3r.pl:
> -    use local::lib '--no-create', "$FindBin::Bin/local-lib";
> +    use lib '--no-create', "$FindBin::Bin/local-lib";

This is not really a valid change.

"lib" doesn't accept --no-create.

(local::lib and lib are very different and aren't considered drop-ins for each other)

Also, the entire presence of a local-lib here basically amounts to "stop using system dependencies and use bundled ones"

Subsequently, valid options may be:

> -    use local::lib '--no-create', "$FindBin::Bin/local-lib";
> +    use lib "$FindBin::Bin/local-lib";

Or


> -    use local::lib '--no-create', "$FindBin::Bin/local-lib";

Wherein you fix dependencies after the second of these.
Comment 5 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2017-05-06 23:38:13 UTC
> > -    use local::lib '--no-create', "$FindBin::Bin/local-lib";
> > +    use lib "$FindBin::Bin/local-lib";


Actually, even this may be wrong, I seem to recall local::lib and lib using slightly different directory structures, and you may need something like:


+    use lib "$FindBin::Bin/local-lib/lib";

Instead.
Comment 6 Philipp Psurek 2017-05-07 01:27:24 UTC
(In reply to Kent Fredric (IRC: kent\n) from comment #5)
Thank you for your explanations. Unfortunately I can't fix this problem. I also got no errors at runtime.

Because this is a fluid git ebuild I suggest to use sed with the correct solution instead of patching. A patch might break more frequently even with minor upstream changes.
Comment 7 Amy Liffey gentoo-dev 2017-05-07 06:58:29 UTC
(In reply to Philipp Psurek from comment #6)
> (In reply to Kent Fredric (IRC: kent\n) from comment #5)
> Thank you for your explanations. Unfortunately I can't fix this problem. I
> also got no errors at runtime.
> 
> Because this is a fluid git ebuild I suggest to use sed with the correct
> solution instead of patching. A patch might break more frequently even with
> minor upstream changes.

It worked for me.. weird.. :D
Comment 8 Philipp Psurek 2017-05-07 13:15:15 UTC
“Unfortunately I can't fix this problem” means I can't apply “something like [this]” to an ebuild. Only a real solution.

there is:

 6 BEGIN {
 7     use FindBin;
 8     use lib "$FindBin::Bin/lib";
 9     use local::lib '--no-create', "$FindBin::Bin/local-lib";
10 }

line 9 gives this error:

"
Can't locate local/lib.pm in @INC (you may need to install the local::lib module) (@INC contains: /usr/bin/lib /etc/perl /usr/local/lib64/perl5/5.24.1/x86_64-linux-thread-multi /usr/local/lib64/perl5/5.24.1 /usr/lib64/perl5/vendor_perl/5.24.1/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.24.1 /usr/local/lib64/perl5 /usr/lib64/perl5/vendor_perl /usr/lib64/perl5/5.24.1/x86_64-linux-thread-multi /usr/lib64/perl5/5.24.1 .) at /usr/bin/slic3r.pl line 9.
BEGIN failed--compilation aborted at /usr/bin/slic3r.pl line 9.
"

and slic3r won't start. I might miss some dependency missing in ${RDEPEND}. Removing “local::” from “local::lib” or deleting the entire line 9 fixes the start up problem. Removing “local::” triggers no warnings and no errors even if it might be wrong.. weird.. :D
Comment 9 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2017-05-07 18:03:45 UTC
(In reply to Philipp Psurek from comment #8)
> and slic3r won't start. I might miss some dependency missing in ${RDEPEND}.

The reason this happens is, "local::lib" is more or less a hack designed for working with containerised CPAN install trees.

Typically, people use `cpanm` with a local::lib path, which installs all their dependencies into that target path ( "$FindBin::Bin/local-lib" ), and then the code invocation of `use local::lib` re-uses that path ( and sets a few ENV vars like PATH )

And so, this structure is a "Cheat" to help novices simply clone the repo and get going with minimal effort, and is helpful also during development.

Subsequently, its invocation is redundant from Gentoo's perspective, because we have a real dependency system that end users can use trivially.

You could thus make the "failure" part of "can't find local::lib" go away by depending on dev-perl/local-lib 

But IME, invoking local::lib once installed is an error, you might just get lucky and the superflouous `use local::lib` might do nothing at best, ... but worst case, it will treat /usr/lib/ like a perl5 @INC and that could have some side effects :)
Comment 10 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2017-05-07 18:11:52 UTC
(In reply to Philipp Psurek from comment #8)
> start up problem. Removing “local::” triggers no warnings and no errors even
> if it might be wrong.. weird.. :D

Well, that's because 

> use lib

uses the syntax

> use lib "List", "of", "Literal", "paths","that", "may", "not", "exist"

And so subsequently, 

"--no-create"

Is a legal path which gets inserted into @INC

The fun thing is "--no-create" is a *relative* path, which means you just created a security vulnerability if anyone created a dir called "--no-create" and put infected versions of Perl modules in it, and then gets root to run slic3r.pl from that paths parent directory ;) 

/tmp $ mkdir --  "--no-create"
/tmp $ echo "die q[Vulnerable]" >> ./--no-create/Infected.pm
/tmp $ perl -e' use lib "--no-create"; use Infected '
Vulnerable at --no-create/Infected.pm line 1.
Compilation failed in require at -e line 1.
BEGIN failed--compilation aborted at -e line 1.

So, yeah.
Comment 11 Ian Stakenvicius (RETIRED) gentoo-dev 2017-05-08 14:23:57 UTC
OK, so, to be clear, what should I be doing here?  It sounds like I should just be nuking any instance of "use local::lib" or whatever the string is, entirely....?
Comment 12 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2017-05-08 17:32:08 UTC
(In reply to Ian Stakenvicius from comment #11)
> OK, so, to be clear, what should I be doing here?  It sounds like I should
> just be nuking any instance of "use local::lib" or whatever the string is,
> entirely....?

Yeah. Pretty much.

  sed -i -e '/use\s*local::lib/d' slic3r.pl

Or something like that should be enough to do the trick.
Comment 13 Alexey Shvetsov archtester gentoo-dev 2018-06-06 13:18:37 UTC
This should work for current master and current 1.3.0
Comment 14 Larry the Git Cow gentoo-dev 2018-06-06 13:22:43 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=36d17be523b54b0baae627121f4b7b085f49eb61

commit 36d17be523b54b0baae627121f4b7b085f49eb61
Author:     Alexey Shvetsov <alexxy@gentoo.org>
AuthorDate: 2018-06-06 13:21:39 +0000
Commit:     Alexey Shvetsov <alexxy@gentoo.org>
CommitDate: 2018-06-06 13:22:01 +0000

    media-gfx/slic3r: Version bump
    
    New version of slic3r
    
    Closes: https://bugs.gentoo.org/617640
    Package-Manager: Portage-2.3.40, Repoman-2.3.9

 media-gfx/slic3r/Manifest                          |   1 +
 .../slic3r/files/slic3r-1.3.0-no-locallib.patch    | 609 +++++++++++++++++++++
 media-gfx/slic3r/slic3r-1.3.0.ebuild               | 107 ++++
 3 files changed, 717 insertions(+)