You are not logged in.
Hi,
I try to install Slic3r from the AUR repository. I successfully install on my machine some weeks ago.
Yesterday, I tried like to install it on two others computers but it failed cause of missing file (but it is wrong).
So, I try to find where problems begins. It seems to have an issue with perl dependencies.
However when I use "makepkg", it seems to build properly.
What am I missing and what did I do wrong ?
I use pacaur 4.7.4.
pacaur build :
[david@blueberry Bureau]$ pacaur -S perl-extutils-cppguess
:: Package perl-extutils-cppguess not found in repositories, trying AUR...
:: resolving dependencies...
:: looking for inter-conflicts...
AUR Packages (1) perl-extutils-cppguess-0.11-1
:: Proceed with installation? [Y/n]
:: Retrieving package(s)...
Cloning into 'perl-extutils-cppguess'...
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 0), reused 4 (delta 0)
Unpacking objects: 100% (4/4), done.
:: View perl-extutils-cppguess PKGBUILD? [Y/n] n
:: Checking perl-extutils-cppguess integrity...
==> Making package: perl-extutils-cppguess 0.11-1 (Fri Feb 24 13:18:01 CET 2017)
==> Retrieving sources...
-> Downloading ExtUtils-CppGuess-0.11.tar.gz...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 6794 100 6794 0 0 17089 0 --:--:-- --:--:-- --:--:-- 17070
==> Validating source files with md5sums...
ExtUtils-CppGuess-0.11.tar.gz ... Passed
:: Building perl-extutils-cppguess package(s)...
==> Making package: perl-extutils-cppguess 0.11-1 (Fri Feb 24 13:18:02 CET 2017)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> WARNING: Using existing $srcdir/ tree
==> Starting build()...
sed: can't read lib/ExtUtils/CppGuess.pm: No such file or directory
==> ERROR: A failure occurred in build().
Aborting...
:: failed to build perl-extutils-cppguess package(s)
makepkg build :
[david@blueberry Bureau]$ git clone https://aur.archlinux.org/perl-extutils-cppguess.git
Cloning into 'perl-extutils-cppguess'...
remote: Counting objects: 15, done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 15 (delta 1), reused 14 (delta 0)
Unpacking objects: 100% (15/15), done.
[david@blueberry Bureau]$ cd perl-extutils-cppguess/
[david@blueberry perl-extutils-cppguess]$ makepkg -sri
==> Making package: perl-extutils-cppguess 0.11-1 (Fri Feb 24 13:21:49 CET 2017)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Downloading ExtUtils-CppGuess-0.11.tar.gz...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 6794 100 6794 0 0 35092 0 --:--:-- --:--:-- --:--:-- 35202
==> Validating source files with md5sums...
ExtUtils-CppGuess-0.11.tar.gz ... Passed
==> Extracting sources...
-> Extracting ExtUtils-CppGuess-0.11.tar.gz with bsdtar
==> Starting prepare()...
==> Starting build()...
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for ExtUtils::CppGuess
Writing MYMETA.yml and MYMETA.json
cp lib/ExtUtils/CppGuess.pm blib/lib/ExtUtils/CppGuess.pm
Manifying 1 pod document
==> Starting check()...
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/001_load.t .......... 1/2 # EUMM:$VAR1 = {
# 'dynamic_lib' => {
# 'OTHERLDFLAGS' => ' -lstdc++ '
# },
# 'CCFLAGS' => ' -D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xc++ '
# };
# ---
# MB:$VAR1 = {
# 'extra_linker_flags' => ' -lstdc++ ',
# 'extra_compiler_flags' => ' -D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xc++ '
# };
t/001_load.t .......... ok
t/010_module_build.t .. ok
t/011_makemaker.t ..... ok
All tests successful.
Files=3, Tests=4, 11 wallclock secs ( 0.04 usr 0.01 sys + 4.12 cusr 0.55 csys = 4.72 CPU)
Result: PASS
==> Entering fakeroot environment...
==> Starting package()...
Manifying 1 pod document
Installing /home/david/Bureau/perl-extutils-cppguess/pkg/perl-extutils-cppguess/usr/share/perl5/vendor_perl/ExtUtils/CppGuess.pm
Installing /home/david/Bureau/perl-extutils-cppguess/pkg/perl-extutils-cppguess/usr/share/man/man3/ExtUtils::CppGuess.3pm
Appending installation info to /home/david/Bureau/perl-extutils-cppguess/pkg/perl-extutils-cppguess/usr/lib/perl5/core_perl/perllocal.pod
==> Tidying install...
-> Removing empty directories...
-> Removing libtool files...
-> Purging unwanted files...
-> Removing static library files...
-> Stripping unneeded symbols from binaries and libraries...
-> Compressing man and info pages...
==> Checking for packaging issue...
==> Creating package "perl-extutils-cppguess"...
-> Generating .PKGINFO file...
-> Generating .BUILDINFO file...
-> Generating .MTREE file...
-> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: perl-extutils-cppguess 0.11-1 (Fri Feb 24 13:22:04 CET 2017)
==> Installing package perl-extutils-cppguess with pacman -U...
loading packages...
resolving dependencies...
looking for conflicting packages...
Packages (1) perl-extutils-cppguess-0.11-1
Total Installed Size: 0.06 MiB
Last edited by Inglebard (2017-02-25 13:51:50)
Offline
I don't know how pacaur works, but it looks like it isn't downloading ExtUtils-CppGUess-0.11.tar.gz.
Offline
Hi x33a,
Thanks for your answer.
If I compare the content from the git I download and ".cache/pacaur/perl-extutils-cppguess/", all data seems identical. I can do a "makepkg -sri" inside ".cache/pacaur/perl-extutils-cppguess/" without issue.
Offline
Yes, but does `makepkg -e` work? It would seem that's what pacaur is doing. This might actually work now that you've ran makepkg in that directory. But pacaur was not having makepkg extract the source. That was the problem.
EDIT: *headdesk* I should have looked at the PKGBUILD. See below for the cause of the problem.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Hi Trilby,
Thanks for your answer.
You are right, `makepkg -e` does not work. So if I understand well, it's a normal default behavior.
I just check the manpage but I don't find a pacaur parameter which can change this. Should I understand I will not be able to use pacaur to install this kind of AUR package and I should use makepkg (or other helper) instead ?
Last edited by Inglebard (2017-02-24 14:20:36)
Offline
Current version of pacaur uses makepkg in two steps: first "makepkg -o", which should extract the content, then "makepkg -e" that should build with the already extracted content. If that doesn't work with makepkg using these two commands, then the PKGBUILD should likely be fixed by the maintainer (the "export _src_dir" part seems very suspicious here).
Last edited by Spyhawk (2017-02-24 15:10:22)
Offline
Yeah, this is bad packaging. Expecting variables set in prepare to always be available is wrong.
Offline
Hi,
Thanks for all your answers.
I consider the topic as solved caused it's not an issue related to pacaur.
Offline
@Inglebard: check out newest version of pkgbuild and next time post comment yourself when it's an issue related to PKGBUILD
@Spyhawk: thx, your comment helped me to make pkgbuild compatible with that use case (if not for it i would blame pacaur)
Offline
Hi,
@swiftgeek :
I have some issues to register on aur website but it's fix now, I also think to send you an email but I don't. And here is the reason why.
As you can see in this topic, I have a lack of knowledge about how works pacaur and PKGBUILD. I will not comment an AUR package until I understand a little bit more how works all this stuff and know where the issue come from. I also notice nobody else have the problem so maybe I am the only person with this issue (so maybe need to check my installation). Also, I really enjoy all your work to bring softwares to the aur (it's already awesome), and comment something like "I have a problem" without search and bring a fix to the author is not enough in my point of view. But be sure, I will contact you if I encounter other issues (By the way some other perl dependencies seems to have the same issue, so be ready ).
Offline