Warning: file_exists(): open_basedir restriction in effect. File(/srv/http/vhosts/aur.archlinux.org/public/web/locale//en/LC_MESSAGES/aurweb.mo) is not within the allowed path(s): (/srv/http/vhosts/aur-dev.archlinux.org/:/etc/aurweb/) in /srv/http/vhosts/aur-dev.archlinux.org/public/web/lib/streams.php on line 90
AUR (en) - emacs-org-mode

Notice: Undefined variable: name in /srv/http/vhosts/aur-dev.archlinux.org/public/web/lib/pkgfuncs.inc.php on line 248

Package Details: emacs-org-mode 9.0-1

Git Clone URL: https://aur-dev.archlinux.org/emacs-org-mode.git (read-only)
Package Base: emacs-org-mode
Description: Emacs Org Mode
Upstream URL: http://orgmode.org/
Licenses: GPL
Submitter: tgirod
Maintainer: drdissector
Last Packager: drdissector
Votes: 101
Popularity: 0.342132
First Submitted: 2008-07-02 18:45
Last Updated: 2016-11-10 01:38

Latest Comments

1 2 3 4 5 6 Next › Last »

milouse commented on 2014-08-20 07:10

Thanks @domanov for your comment on 2014-08-06 07:39. I was seeing the same thing as @cedricmc, but was too lazy to asks. Much clear now why we see this warning.

And of course thanks for your awesome packaging work and reactivity :)

domanov commented on 2014-08-19 11:24

Bumped to the 8.2.7c. Enjoy!

abstracity commented on 2014-08-19 10:44

Emacs 8.2.7c is out, "a bugfix release:" https://twitter.com/bzg2/status/494397367932956672

domanov commented on 2014-08-06 07:39

Yes @cedricmc, this warning is ignorable since it is only due to the presence of compiled lisp, for building which the original source directory needs to be stored in some lisp variable at compile time (think about autogenerated makefiles) and then gets logged in the .elc files.
The 2 autogenerated files "org-version" and "org-loaddefs" take care of this. Every emacs package having .elc files will give out this warning, nothing to do about it, and completely safe.

cedricmc commented on 2014-08-06 01:47

With a fully updated system, I get:

WARNING: Package contains reference to $pkgdir

In fact, ``grep -R "$(pwd)/pkg" src/'' gives

src/org-8.2.7b/lisp/org-version.el:(defvar org-odt-data-dir "$(pwd)/pkg/emacs-org-mode/usr/share/emacs/etc/org"
src/org-8.2.7b/lisp/org-loaddefs.el:(defvar org-odt-data-dir "$(pwd)/pkg/emacs-org-mode/usr/share/emacs/etc/org" "\

Is this normal?

domanov commented on 2014-07-25 18:28

Well, I've always used makepkg --source to do my stuff, I missed that now there is need for .AURINFO and that mkaurball takes care of that. I found it out as I tried to upload the srcball to AUR.

I then just did a "pacman -Ss mkaurball" and nothing came up. Then "packer -Ss mkaurball and it gave me "pkgbuild-introspection-git" - so I just installed that.

haawda commented on 2014-07-25 18:22

pkgbuild-introspection from [community] did not work?

domanov commented on 2014-07-25 10:06

Bumped to the "new" 8.2.7b. Also had to install pkgbuild-introspection-git from AUR to get "mkaurball". I somehow missed that. Enjoy!

ckruse commented on 2014-07-25 08:13

Could you do an upgrade to 8.2.7b?

kgunders commented on 2014-05-20 17:09

I think the version you get from melpa or orgmode.org's ELPA archive is the developement version. So if you want stable you may well be better off using the arch/aur package. AUR and pacman also provide better package management w.r.t. managing version rollbacks. Since org is Emacs built-in, once you uprade via ELPA there's no way to roll back, other than manually deleting the updated package from e.g. ~/.emacs.d/elpa/

In short, ELPA is kind of lame as a package management system. RSM is anal about license (I'm into FOSS but not a license nazi, MIT, BSD, Apache - it's all good) and dead tree copyright assignments so many .el authors don't bother with the hassle of submitting to gnu's elpa archives. So rather than elpa being authoritative source for one stop shopping, it's outdated and pretty much useless. Hence most .el authors are opting for second party repos such as MELPA & Marmalade. The main benefit of Emacs package system, as far as I can discern, is for users who don't have requisite permissions for installing packages system wide. Also, that having all your emacs extensions/tweaks under e.g. ~/.emacs.d makes them more portable for end user - just copy that dir and subdir to any machine.

I'm far from emacs guru so take all of above with dose of salt. I did, however, inquire about this packaging mess on #emacs recently and it seems the gurus' eschew elpa, etc. and just manage their packages manually, most of which seem to have github repos, in an appropriate subdir under git control. This seems like a lot of work if you have lots of stuff but I guess on reason the gurus are gurus is that they live in emacs.

Hope this helps some.