Package Details: emacs-org-mode-git 8.3.5.996.ga9fe21f-1

Git Clone URL: https://aur.archlinux.org/emacs-org-mode-git.git (read-only)
Package Base: emacs-org-mode-git
Description: Emacs Org Mode from git
Upstream URL: http://orgmode.org/
Licenses: GPL
Conflicts: emacs-org-mode
Provides: emacs-org-mode=8.3.5.996.ga9fe21f
Submitter: zhuqin
Maintainer: haawda
Last Packager: haawda
Votes: 16
Popularity: 0.103956
First Submitted: 2009-04-04 06:40
Last Updated: 2016-07-23 15:47

Dependencies (7)

Required by (0)

Sources (1)

Latest Comments

haawda commented on 2015-08-27 17:06

done, thanks.

taurgal commented on 2015-08-27 09:17

Please remove the last line of the PKGBUILD, that is:
rm $pkgdir/usr/share/emacs/site-lisp/org/org-{loaddefs.el,version.el}

My installation would not work without org-loaddefs.el.

haawda commented on 2015-03-03 17:02

Please file a bug report upstream.

Pank commented on 2015-03-03 12:55

Re:
> I just removed the two files from the package.

I now get this error when trying to use Gnus.

> WARNING: No org-loaddefs.el file could be found from where org.el is loaded.
> You need to run "make" or "make autoloads" from Org lisp directory

Pank commented on 2015-03-02 22:40

Thanks.

What do you mean by:

> directory for odt exports should IMHO go to a local user's directory.

IMO, etc/org should *definitly* be part of the package. It's necessary for ox-odt.el.

haawda commented on 2015-03-02 22:32

I just removed the two files from the package. org-loaddefs is anyway only needed for the compilation process, and the directory for odt exports should IMHO go to a local user's directory.

Pank commented on 2015-03-02 10:31

haawda, do you think it would be possible to adjust org-loaddef.el and org-version.el to not point towards /tmp/makepkg (or whereever you build your packages)? In particular, org-odt-data-dir is wrong, which causes some problems when using emacs --batch for odt export.

haawda commented on 2014-11-25 19:57

Works fine here, what exactly fails for you?

Pank commented on 2014-11-23 23:46

it seems pkgver() might need to be updated. At least on my computer it produces an error.

haawda commented on 2013-10-06 20:18

Building docs failed here, so I do a "make info" only.

haawda commented on 2013-07-27 22:20

No real change in PKGBUILD. I just wanted to show that this gives something really newer than the othe org-mode package in AUR.

haawda commented on 2013-03-10 12:39

The structure of the contrib subdirectory changed. The PKGBUILD needed to be adjusted.

haawda commented on 2012-09-14 19:01

Added version number to provides-array.

haawda commented on 2012-05-10 19:30

It used to work, but I can confirm it does not anymore with https://, therefore changed to git://.

falsum commented on 2012-05-10 05:37

I had to change _gitroot to "git://orgmode.org/org-mode.git" to be able to build the package.

haawda commented on 2012-04-07 01:30

adopted and borrowed the install file from emacs-org-mode package in AUR.

zhuqin commented on 2012-03-18 11:11

Now it's yours.

escondida commented on 2012-03-17 21:54

Hello,

In light of recent additions to the org source tree (EXPERIMENTAL/, for the new exporter engine, and also the odt templates low-res mentioned, below), would you please update the PKGBUILD to install them? Alternately, I'd be glad to provide an updated PKGBUILD.

Anonymous comment on 2012-02-17 12:52

Exporting to odt fails with the following message: (org-odt): Cannot find factory styles files. See this thread from emacs-orgmode-maillingslist regarding the cause for this error:
http://lists.gnu.org/archive/html/emacs-orgmode/2012-01/msg00605.html

listx commented on 2011-09-26 18:30

Two things:
(1) Again, for initial clones, you should use git's `--depth 1' option to save yourself from downloading at least 20MB of useless revision history (this 20MB figure will grow with time, as the source repo gets larger).
(2) The creation of the temporary build directory, $srcdir/$_gitname-build, is not necessary... you can just go into $srcdir/$_gitname itself and do all the builds there.

myles commented on 2011-08-31 10:37

Please change:
- cp -r contrib/{babel,lisp,scripts} $pkgdir/usr/share/emacs/site-lisp/org_contrib
+ cp -r contrib/{babel,lisp,scripts,odt} $pkgdir/usr/share/emacs/site-lisp/org_contrib
Thanks

myles commented on 2011-08-31 10:36

Please change:
- cp -r contrib/{babel,lisp,scripts} $pkgdir/usr/share/emacs/site-lisp/org_contrib
+ cp -r contrib/{babel,lisp,scripts,odt} $pkgdir/usr/share/emacs/site-lisp/org_contrib || return 1
Thanks

listx commented on 2011-03-18 21:53

@dolby: The whole point of doing an initial shallow clone with --depth 1 is to *save time* from downloading needless, old commits. For org-mode, this means saving ~20MB off the initial download time (my mistake in the earlier post re: 50MB of revision history). I don't think anyone here (for this package) cares about saving *disk space*, which is what you are arguing about in the discussion at emacs-git. The concern for disk space does not make much sense as well here, because there is the line "rm -rf $srcdir/$_gitname-build" at the very end, like it should be. I have no clue why the emacs-git package does not delete the build directory (like this and other *-git packages) after the build is complete --- am I missing something?

And the maintainer there talks about "merge issues" when using a shallow clone. Merging what? (The right terminology is *pulling* in the upstream repo's commits, not merging). As far as I can tell all of these -git packages on AUR merely pull in the latest changes from the upstream git repo. Pulling in the latest commits work just fine for both regular clones AND shallow clones. You say note "the major disadvantage of being able to push patces to the emacs sources tree etc." for shallow clones --- I do not understand this argument. I think you are trying to say that users won't be able to create patches from their shallow clone and push patches (email them) to the upstream developers. And my response is: (1) who in their right mind would do development work inside the src directory of a PKGBUILD, and (2) how many *-git PKGBUILD users are actually developers?

listx commented on 2011-03-18 21:40

Oh, and for this package, because there is a line "rm -rf $srcdir/$_gitname-build" at the very end, the disk space issue does not even apply.

listx commented on 2011-03-18 20:31

Just want to add: the whole disk space argument has a very big flaw because the -build directories are always deleted (rm -rf $srcdir/$_gitname-build). So I don't really see any reason why one should favor a full clone instead of a shallow clone.

listx commented on 2011-03-18 19:32

@dolby: The whole point of doing an initial shallow clone with --depth 1 is to *save time* from downloading needless, old commits. For org-mode, this means saving ~20MB off the initial download time (my mistake in the earlier post re: 50MB of revision history). I don't think anyone here (for this package) cares about saving *disk space*, which is what you are arguing about in the discussion at emacs-git (where saving disk space may well indeed be a concern simply because of emacs-git's very large (hundreds of MB) size).

And the maintainer there talks about "merge issues" when using a shallow clone. Merging what? (The right terminology is *pulling* in the upstream repo's commits, not merging). As far as I can tell all of these -git packages on AUR merely pull in the latest changes from the upstream git repo. Pulling in the latest commits work just fine for both regular clones AND shallow clones. You say note "the major disadvantage of being able to push patces to the emacs sources tree etc." for shallow clones --- I do not understand this argument. I think you are trying to say that users won't be able to create patches from their shallow clone and push patches (email them) to the upstream developers. And my response is: (1) who in their right mind would do development work inside the src directory of a PKGBUILD, and (2) how many *-git PKGBUILD users are actually developers?

Ideally, I think, *-git packages that are less than, say, 100MB, should use shallow clones and any package larger than that should just do regular clones to avoid (as you noted re: hardlinks) wasting disk space.

listx commented on 2011-03-18 19:29

@dolby: The whole point of doing a shallow clone with --depth 1 is to *save time* from downloading needless, old commits. For org-mode, this means saving ~20MB off the download time (my mistake in the earlier post re: 50MB of revision history). I don't think anyone here (for this package) cares about saving *disk space*, which is what you are arguing about in the discussion at emacs-git (where saving disk space may well indeed be a concern simply because of emacs-git's very large (hundreds of MB) size).

And the maintainer there talks about "merge issues" when using a shallow clone. Merging what? (The right terminology is *pulling* in the upstream repo's commits, not merging). As far as I can tell all of these -git packages on AUR merely pull in the latest changes from the upstream git repo. Pulling in the latest commits work just fine for both regular clones AND shallow clones. You say note "the major disadvantage of being able to push patces to the emacs sources tree etc." for shallow clones --- I do not understand this argument. I think you are trying to say that users won't be able to create patches from their shallow clone and push patches (email them) to the upstream developers. And my response is: (1) who in their right mind would do development work inside the src directory of a PKGBUILD, and (2) how many *-git PKGBUILD users are actually developers?

Ideally, I think, *-git packages that are less than, say, 100MB, should use shallow clones and any package larger than that should just do regular clones to avoid (as you noted re: hardlinks) wasting disk space.

Anonymous comment on 2011-03-11 10:21

Re: --depth 1

See the discussion in emacs-git: https://aur.archlinux.org/packages.php?ID=22256

listx commented on 2011-03-06 21:36

Here is a PKGBUILD for those who do not want to download 50MB+ of useless revision history data:

pkgname=emacs-org-mode-git
pkgver=20110306
pkgrel=1
pkgdesc="Emacs Org Mode from git"
arch=('i686' 'x86_64')
url="http://orgmode.org/"
depends=(emacs)
makedepends=('git' 'texlive-core')
license=('GPL')
provides=('emacs-org-mode')
conflicts=('emacs-org-mode')
options=(!zipman)

_gitroot="git://repo.or.cz/org-mode.git"
_gitname="emacs-org-mode"

build() {
cd $srcdir
msg "Connecting to the GIT server...."

if [[ -d $srcdir/$_gitname ]] ; then
cd $_gitname
git pull origin
msg "The local files are updated."
else
git clone --depth 1 $_gitroot $_gitname
fi

msg "GIT checkout done"
msg "Starting make..."

rm -rf $srcdir/$_gitname-build
cp -r $srcdir/$_gitname $srcdir/$_gitname-build

cd $srcdir/$_gitname-build

make all doc || return 1
make prefix=$pkgdir/usr lispdir=$pkgdir/usr/share/emacs/site-lisp/org install install-info || return 1
install -d $pkgdir/usr/share/doc/$_gitname || return 1
cp doc/*.pdf $pkgdir/usr/share/doc/$_gitname || return 1
install -d $pkgdir/usr/share/emacs/site-lisp/org_contrib || return 1
cp -r contrib/{babel,lisp,scripts} $pkgdir/usr/share/emacs/site-lisp/org_contrib || return 1

rm -rf $srcdir/$_gitname-build
}

listx commented on 2011-02-26 04:02

I suggest:

git clone --depth 1 <url>

because no one here cares about the thousands of past commits/revision history. This should make the initial clone *much* faster, especially as the project grows with more and more commits...