Package Details: rust-git 3:1.0.0.beta.2833.gb850046-2

Git Clone URL: https://aur.archlinux.org/rust-git.git (read-only)
Package Base: rust-git
Description: A safe, concurrent, practical language from Mozilla.
Upstream URL: http://www.rust-lang.org/
Keywords: mozilla rust
Licenses: MIT, Apache
Conflicts: rust
Provides: rust
Submitter: mrshpot
Maintainer: spider-mario
Last Packager: spider-mario
Votes: 25
Popularity: 0.000903
First Submitted: 2012-01-21 11:30
Last Updated: 2016-07-01 21:30

Dependencies (7)

Required by (50)

Sources (10)

Latest Comments

eduardosm commented on 2016-07-01 10:46

rust.nanorc has been moved to the upstream nano package and it's been removed from rust/nano-config, so you should remove the lines

install --directory "$pkgdir"/usr/share/nano/
cp -a "$srcdir"/nano-config/*.nanorc "$pkgdir"/usr/share/nano/

(and "git+https://github.com/rust-lang/nano-config.git" from source too)

See: https://github.com/rust-lang/nano-config/blob/master/README.md

spider-mario commented on 2016-03-26 23:22

This should be fixed, thanks.

intelfx commented on 2016-03-26 14:50

> file owned by 'gtksourceview3' and 'rust-git': 'usr/share/gtksourceview/3.0/language-specs/rust.lang'

So, please, don't clone & package gedit-config.

spider-mario commented on 2015-03-11 06:23

I think makepkg is slightly confused by the fact that this is a split package where both packages don’t have the same architecture… (rust-doc-git is an “any” package.)

I suppose a workaround would be to make rust-doc-git arch-specific, even though it’s not. Would that seem acceptable?

MusicidalOtaku commented on 2015-03-10 22:31

After the build process pacman complains it can't find the package file... It succeeded before...
Installing with pacaur.

spider-mario commented on 2015-02-02 09:52

Thanks, I will fix it as soon as I can.

A build-time dependency on perl is not needed, however, as perl is not only part of the base group, but needed by git as well.

gbs commented on 2015-02-02 03:12

As of https://github.com/rust-lang/rust/pull/21738, editor files are not on the main rust repo anymore. See issue for new locations.

This should list perl on makedepends, since it's used on prepare(). Or replace that with, removing the noextract=(…) line:
`
git submodule init
for repo in compiler-rt jemalloc llvm hoedown; do
git config submodule.src/${repo}.url "$srcdir/$repo"
done
git submodule update
`
rust-doc package is missing the license files (and btw, 'MIT' does not need 'custom:').

The files "$pkgdir"/usr/lib/rustlib/{components,manifest-{rustc,rust-docs},rust-installer-version} are only used by rust-installer, and can be removed. They would conflict if something using the installer was already installed.

And just a cosmetic change, the rust repo is not in mozilla/rust anymore, but in rust-lang/rust (even though it redirects to the right place).

spider-mario commented on 2015-01-05 08:10

It works for me, I suspect it has been fixed upstream.

If not, could you perhaps upload the entire build log to some pastebin, please?

heinrich5991 commented on 2015-01-04 18:47

@Foucault Same thing happens to me.

Foucault commented on 2015-01-02 11:34

Has anyone managed to build the latest "master". It always fails for me late into build with the following error

gen-install-script: processing /home/build/abs/rust-git/src/rust/src/rust-installer/gen-install-script.sh args
gen-install-script:
gen-install-script: CFG_PRODUCT_NAME := Rust
gen-install-script: CFG_VERIFY_BIN := rustc
gen-install-script: CFG_REL_MANIFEST_DIR := rustlib
gen-install-script: CFG_SUCCESS_MESSAGE := Rust-is-ready-to-roll.
gen-install-script: CFG_OUTPUT_SCRIPT := tmp/dist/rust-0.13.0-dev-x86_64-unk ...
gen-install-script: CFG_LEGACY_MANIFEST_DIRS := rustlib,cargo
gen-install-script:
gen-install-script: validating /home/build/abs/rust-git/src/rust/src/rust-installer/gen-install-script.sh args
gen-install-script:
make[1]: Leaving directory '/home/build/abs/rust-git/src/rust'
sh: ../../tmp/dist/rust-docs-0.13.0-dev-x86_64-unknown-linux-gnu/install.sh: No such file or directory
/home/build/abs/rust-git/src/rust/mk/install.mk:22: recipe for target 'install' failed
make: *** [install] Error 127

spider-mario commented on 2014-10-22 06:33

Thanks a lot for your feedback, $SRCDEST indeed appears to be the right variable to use.

abandonedaccount commented on 2014-10-22 05:16

@spider-mario very nice, using the info you provided, replacing $startdir with $SRCDEST works as intended; maybe worth noting what's my env:
PKGDEST=/tmp/packages
SRCDEST=/tmp/sources
SRCPKGDEST=/tmp/srcpackages
BUILDDIR=/tmp/makepkg
and $startdir is /home/emacs/build/rust-git
Thanks.

spider-mario commented on 2014-10-20 18:20

@Svenstaro: I can’t reproduce the issue. What are your MAKEFLAGS? Perhaps we should go back to `options=(!makeflags)`.

@emanueLczirai: weird, it works for me. :/ The way the script works is that for each line in .gitmodules that looks like “$url = (...)/$submodule[.git]”, if $startdir/$submodule/ is an existing directory then the line is replaced with “$url = $startdir/$submodule/”.

abandonedaccount commented on 2014-10-20 11:25

The perl script in prepare() doesn't seem to modify .gitmodules anymore and they are downloaded/cloned by the ./configure instead of using the repos that pacman already downloaded/cloned. I've no idea how to fix it currently because I don't know perl. Someone please look into it? Thanks.

Svenstaro commented on 2014-10-17 23:05

For some reason, I end up with an empty package after making this. spider-mario, please look into it.

Binero commented on 2014-07-09 09:50

This package seems to 'make clean' automatically. Rather annoying due to the time it consumes compiling.

gsnedders commented on 2014-06-10 13:29

Bah, I must be blind! I had a quick look at options and managed to glaze over the "!" and got slightly confused but moved on. But yes — parallel builds appear to work now.

heinrich5991 commented on 2014-06-09 22:47

Maybe you could make a blacklist isntead of a whitelist. Also note that it currently misses all files directly in the doc directory (not the subfolders).

spider-mario commented on 2014-06-09 21:58

The goal was to avoid copying useless .aux, .log and .out files, but indeed, missing useful files is worse.

heinrich5991 commented on 2014-06-09 20:36

The docs are not properly copied, it misses the JS files at least. Why does it make a selection based on file extension?

spider-mario commented on 2014-06-03 16:41

It’s ignored because of '!makeflags' in the `options` array. I think that I added that option because parallel builds didn’t seem to work.

If they work now, I’ll happily remove it. :)

gsnedders commented on 2014-06-03 16:35

MAKEFLAGS seems to be ignored, though I can't immediately see why. Having to do non-parallel builds makes it a lot slower. :(

spider-mario commented on 2014-04-05 07:48

I think I’ll just make the package provide `rust` now. Its version format sufficiently resembles that of `rust` in [community] now that makepkg natively supports VCS packages and let them have a pkgver() function.

spider-mario commented on 2014-04-04 20:22

Actually, I think I’ll just make the package provide `rust` now. Its version format sufficiently resembles that of `rust` in [community] now that makepkg natively supports VCS packages and let them have a pkgver() function.

spider-mario commented on 2014-04-04 20:15

Actually, the out-of-date notification comes from someone else (H3g3m0n), and it’s justified since 0.10 is out, which means that the `provides` field of this package should be updated. (I’m working on it.)

Thanks for explaining the point of VCS packages to Apes, though.

thestinger commented on 2014-04-04 19:50

Also, please only use out-of-date flags when something needs to be updated to a new release. It shouldn't be used whenever there is a problem with the package.

thestinger commented on 2014-04-04 19:49

Grabbing the HEAD of the master branch is what a VCS package is for in the first place. If you want the tagged release, use the rust package in [community].

Apes commented on 2014-04-04 19:47

The PKGBUILD just grabs whatever is on the HEAD of the master branch of the rust git project. It would be better to grab the tarball for one of the releases, or at the very least use a specific commit or tag.

spider-mario commented on 2014-03-30 12:40

Done, thank you.

spider-mario commented on 2014-03-30 10:34

There’s already a call to chrpath (I think I added it before e715cdba31ae2bfee603cfe0c56260390ec36f1c) but --disable-rpath would, indeed, avoid an unnecessary step, as well as remove a build-time dependency on chrpath.

thestinger commented on 2014-03-30 04:56

This should pass --disable-rpath --disable-verify-install, to avoid adding incorrect runpaths and to disable the newly added installation verification.

thestinger commented on 2014-03-09 00:31

@HalosGhost: It's intended to be that way. Git has a `describe` command and versions are described as `${last_tag}-${commits_since_last_tag}-g${commit_id}`.

HalosGhost commented on 2014-03-09 00:24

Perhaps it is just me, but I find it odd that the pkgver reports this as being based on 0.9.

All the best,

thestinger commented on 2014-02-07 00:01

The nightly build will be fixed after https://github.com/mozilla/rust/pull/12076 lands. It passes `--disable-rpath` to configure and this option broke a few days ago.

colemickens commented on 2014-02-06 01:19

Sorry, I'd unflag this if I could. I accidentally flagged this when thinking of thestinger's binary repo being out-of-date. My mistake.

thestinger commented on 2013-11-16 22:43

It needs to be updated to include `options=(staticlibs)` since the default is now to remove them:

https://github.com/thestinger/packages/tree/master/rust-git

Note that there's a nightly repository you can use instead of building yourself: http://pkgbuild.com/~thestinger/repo/

thestinger commented on 2013-11-16 22:41

It needs to be updated to flip off removing static libraries:

https://github.com/thestinger/packages/tree/master/rust-git

idupree commented on 2013-11-16 20:02

The `rustc` from this PKGBUILD is giving me an error when used on a "hello world" program. rustc built manually by "git clone https://github.com/mozilla/rust; ./configure --prefix=/home/me/inst; make; make install" works fine.

% rustc hello.rs
error: linking with `cc` failed: exit code: 1
note: cc arguments: -L/usr/lib/rustc/x86_64-unknown-linux-gnu/lib -m64 -o hello hello.o -L/usr/lib/rustc/x86_64-unknown-linux-gnu/lib -lstd-6425b930ca146ae9-0.9-pre -L/usr/lib/rustc/x86_64-unknown-linux-gnu/lib -lrustuv-a13edc95d75df17-0.9-pre -L/Users/me/programming/rust/.rust -L/Users/me/programming/rust -lrt -ldl -lm -lmorestack -lrustrt -Wl,-rpath,$ORIGIN/../../../../usr/lib/rustc/x86_64-unknown-linux-gnu/lib -Wl,-rpath,/usr/lib/rustc/x86_64-unknown-linux-gnu/lib
note: /usr/bin/ld: cannot find -lmorestack
collect2: error: ld returned 1 exit status

mindcat commented on 2013-11-01 07:33

lines 39: make DESTDIR="$pkgdir" install
Please change to this.
lines 39: make DESTDIR="$pkgdir" CFG_MANDIR="$pkgdir/usr/share/man" install

or this error. http://paste.ubuntu.com/6339858/

thestinger commented on 2013-09-22 17:37

It's a known issue and fixing it by making a new snapshot is in-progress.

LeonidasXIV commented on 2013-09-22 12:09

Todays build fails:

x86_64-unknown-linux-gnu/stage0/bin/rustc: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory
make: *** [x86_64-unknown-linux-gnu/stage0/lib/rustc/x86_64-unknown-linux-gnu/lib/libstd.so] Error 127

spider-mario commented on 2013-09-08 10:57

Appearently, the reason why the patch doesn’t apply anymore is that the problem has been fixed upstream: https://github.com/mozilla/rust/commit/75afcffc2ffdbac1d0a837d8407ae5720dce9631

\o/

thestinger commented on 2013-09-07 22:02

It has make dependencies on both python2 and python by default. I work around this with `sed` in the PKGBUILD I use for the nightly build repository:

https://github.com/thestinger/packages/blob/master/rust-git/PKGBUILD
http://pkgbuild.com/~thestinger/repo/

LeonidasXIV commented on 2013-09-07 21:54

Thanks for looking into it, I appreciate it. Unfortunately, it fails even earlier now:

==> Starting prepare()...
error: patch failed: mk/rt.mk:178
Falling back to three-way merge...
Applied patch to 'mk/rt.mk' with conflicts.
U mk/rt.mk
==> ERROR: A failure occurred in prepare().
Aborting...

spider-mario commented on 2013-09-07 14:36

Thanks, it should be fixed now. Please let me know whether it works.

LeonidasXIV commented on 2013-09-07 11:50

Looks like it uses Python 3 somewhere where Python 2 is expected:

(cd /tmp/yaourt-tmp-leonidas/aur-rust-git/src/rust/src/libuv/ && ./gyp_uv -f make -Dtarget_arch=x64 -D ninja -Goutput_dir=/tmp/yaourt-tmp-leonidas/aur-rust-git/src/rust/x86_64-unknown-linux-gnu/rt/stage0/libuv --generator-output /tmp/yaourt-tmp-leonidas/aur-rust-git/src/rust/x86_64-unknown-linux-gnu/rt/stage0/libuv)
File "./gyp_uv", line 44
print 'Error running GYP'
^
SyntaxError: invalid syntax

spider-mario commented on 2013-09-05 16:35

Fixed, thanks! :)

draven commented on 2013-09-05 14:20

Hi!

At the very end the command
if which emacs 2> /dev/null; then make; fi
fails for me complaining there is no Makefile.

Perhaps using
emacs --eval '(byte-recompile-directory "/the/directory")' -Q --batch
would do the trick

thestinger commented on 2013-06-21 04:13

By the way, I have daily builds of rust-git in a repository:

[thestinger]
SigLevel = Optional
Server = http://pkgbuild.com/~thestinger/repo/$arch

spider-mario commented on 2013-05-01 21:39

Applied, thanks. :)

thestinger commented on 2013-05-01 21:34

The llnextgen/naturaldocs optdepends can be removed now, and the pandoc one should be changed to haskell-pandoc.

thestinger commented on 2013-01-30 00:35

@ackalker: It's reported upstream already and is harmless (just annoying), which is why it hasn't gotten any attention yet.

ackalker commented on 2013-01-30 00:31

s/hear/here/ # ;(

ackalker commented on 2013-01-30 00:30

After building and installing this package, and every time something runs 'ldconfig', I get these warnings:

ldconfig: File /usr/lib/libcargo.so is empty, not checked.
ldconfig: File /usr/lib/librusti.so is empty, not checked.
ldconfig: File /usr/lib/librustdoc.so is empty, not checked.
ldconfig: File /usr/lib/librustc.so is empty, not checked.

Probably an upstream bug, but posted hear just FYI.

thestinger commented on 2013-01-03 07:27

Would be nice if this included provides=(rust) and conflicts=(rust). Thanks!

Anonymous comment on 2012-12-23 20:40

ah, ok, that makes sense. But you certainly want to avoid copying the Makefile don't you?

It *did* work, btw. :) Thanks!

spider-mario commented on 2012-12-23 19:35

The thing is, if the .el files are copied too, then the user can install emacs after building the package and still be able to use the mode (though it will be slower than if it has been precompiled). That is the reason why only the call to make is in the if.

Anonymous comment on 2012-12-23 19:03

I'm trying it out now, but I made the following modifications:

cp -a *.elc "$pkgdir/usr/share/emacs/site-lisp/" # copy just the .elc files

It also might be useful to wrap this whole section in the if:

if which emacs > /dev/null;
cd src/etc/emacs;
make;
install --directory "$pkgdir/usr/share/emacs/site-lisp/";
cp -a *.elc "$pkgdir/usr/share/emacs/site-lisp/"
echo "enable rust-mode in emacs by adding (require 'rust-mode) to your ~/.emacs file"
fi

Something along these lines perhaps.

spider-mario commented on 2012-12-23 18:04

I’ve just given it a try, please let me know whether it works.

Anonymous comment on 2012-12-23 17:43

For emacs, you need to first build the files in the emacs directory. I'm not sure what the pre-reqs for this are (you at least need emacs installed though).

the emacs files are in src/etc/emacs. You need to run make from this directory. Then you copy all the .elc files from there to /usr/share/emacs/site-lisp/

After that you need to add (require 'rust-mode) to your ~/.emacs file (This can probably just be some post-install output for the user to act on). I'm not sure how to do all this in the PKGBUILD right now. I'll look into (and I'm testing some stuff now) and I'll hopefully get back to you with a patched PKGBUILD, but if anyone can do this quickly off the top of their head, that'd be great too :)

spider-mario commented on 2012-12-10 19:23

Done for Vim, thanks!

Unfortunately, I don’t use Emacs either, so even if I tried to do the same for the Emacs files, I wouldn’t be able to check that it works.

If someone can make it work, I’ll be glad to add it to the PKGBUILD.

thestinger commented on 2012-12-10 14:40

It would be great if you could install the Vim and Emacs files that ship with the rust source. For vim, you just need this:

mkdir -p "$pkgdir/usr/share/vim"
cp -a src/etc/vim "$pkgdir/usr/share/vim/vimfiles"

I'm unsure about what to do with the Emacs files + Makefile though, so an Emacs user will have to step forward with that info :).

mrshpot commented on 2012-10-19 07:00

Sorry, due to lack of time I'm disowning it so somebody can actually fix it.

Svenstaro commented on 2012-10-12 16:48

This PKGBUILD has a bunch of problems.

1) You are not using a packaging() function
2) You are still using || return 1
3) You are using the wrong DESTDIR
4) You are not using Maintainer or Contributor in the comment but your custom "Author"
5) You don't need the python hack anymore
6) You shouldn't manually have to copy docs (did you make an upstream bug report?)

Anonymous comment on 2012-10-12 16:06

Files are being installed in the wrong directory (/usr/usr instead of just /usr), fixed PKGBUILD: http://p.blicky.net/86t6s (only changes the DESTDIR= line).

Anonymous comment on 2012-10-12 11:39

Anybody with problems on x86_64, if so what did you do to solve this?

I am working with the official repos and python2, but at the end of the build I
have problems with packaging the documentation which kill the whole build. I've tried
modifiying the PKGBUILD with no success, any ideas?

thanks for the PKGBUILD though

mrshpot commented on 2012-01-21 15:06

llvm-build (src/llvm/llvm-build/llvm-build) breaks with python3 [1].
I saw those errors during the LLVM build and figured it would be best to roll back to python2.
The carpet-bomb replacement might really be overkill, though -- the LLVM build takes a long time on my machine and I wanted to have rust working ASAP.
If the thing builds properly with python3 for everything except llvm-build, let me know (or I'll try that later myself).

[1]:
$ pwd
/home/mrshpot/build/rust-git/src/llvm/utils/llvm-build

$ python llvm-build
Traceback (most recent call last):
File "llvm-build", line 3, in <module>
import llvmbuild
File "/home/mrshpot/build/rust-git/src/llvm/utils/llvm-build/llvmbuild/__init__.py", line 1, in <module>
from main import main
ImportError: No module named main

$ python2 llvm-build
# runs with no errors

spider-mario commented on 2012-01-21 12:04

Are you sure you need to replace “python” with “python2”?

This page: https://github.com/graydon/rust/wiki/Doc-getting-started
suggests that Python 3 should be used.