UCI question


Forum: Other Help Topics
Topic: UCI question
started by: jpeters

Posted by jpeters on Jan. 28 2008,21:55
I converted vim_7.1.unc over to vim_7.1.uci, and guess I need to create links or export paths so that files it expects in /usr are found in /opt (such as the help menus & spellcheck.  Everything works if I copy /opt/vim_7.1/usr/local/share/vim/vim71/  to /usr.  What is the best (or standard) way to do this.  Thanks

EDIT: For now, I just created a link, which works

Posted by lucky13 on Jan. 28 2008,23:43
I think it's better to recompile since UCI shouldn't affect anything outside /opt or /home. I thought your vim extension was a UCI. I have vim patched through 140-something (the beauty of FreeBSD ports -- I got every available patch), iirc, installed on /opt. No need to recompile if you want me to submit it, but it's on a hard drive currently not in use. Would only need one good reason to put it back in a computer.

EDIT: Okay, I just looked and yours is UNC. I haven't even considered converting between extensions except from DSL to UNC and from tar.gz to UCI. I think it would be kind of messy since the idea is to keep it contained in /opt. My offer stands. :-)

EDIT 2: Now over 240 patches for vim 7.1. Some are pretty noteworthy (memory leaks, crashing, various bugs, etc.), some don't pertain to Linux.
< ftp://ftp.vim.org/pub/vim/patches/7.1/README >

Posted by jpeters on Jan. 29 2008,03:53
Your call....I've got it working as a UCI, since apparently UNC's are going out of favor.  I haven't run into any "bug" problems with my own useage.  I created  one link just to use the spellcheck and help menu's; don't think that's overly messy, but I don't want to break any conventions.
Posted by lucky13 on Jan. 29 2008,05:04
What did you link? I haven't used your extension, but it should overlay /usr leveraging unionfs. If you added links from /opt to those locations it's still overwriting /usr. No?

Edit: And if it's overwriting /usr, is it doing it now via unionfs or RAM as a dsl would?

Posted by stupid_idiot on Jan. 29 2008,06:18
Hi jpeters:
Some packages have an '--enable-relocatable' or similar option in the 'configure' script -- I think this allows the executable to be moved around in the filesystem.
However, the 'configure' file in 'vim71/' does not contain such an option.
Since you said that vim can't find, e.g. the help-menu and spellcheck files, and there isn't an option to enable relocation in the 'configure' script, I think the only two options are:
-- Make a symlink from '/opt/vim-7.1/share/vim/vim71/' to '/usr/local/share/vim/vim71/'.
-- Reconfigure and recompile vim.

Personally, I think recompiling is the best way to solve the problem, since it not only eliminates the manual work of making symlinks, etc, it also saves you the trouble of making a 'user.tar.gz' file with the data files (e.g. help-menu files, spellcheck files) that are in '/usr/local/share/vim/vim71/'.

Re: Reconfiguring
Please pardon me for presuming, but here is a sample configuration for 'vim-7.1.uci':
(The options are in the order they are listed in 'configure --help'.)
Code Sample
CFLAGS='-Os' \
./configure \
--prefix=/opt/vim-7.1 \
--sysconfdir=/etc \
--localstatedir=/var \
--enable-gui=gtk \
--disable-acl \
--disable-gpm \
--disable-nls \
--with-x
Just FYI:
My current practice is to put all the options in a script called 'set_[pkg-name].sh' which I can run and then save somewhere.
e.g. 'set_vim71.sh'
Obligatory question:
Does anyone know of a better name than 'set_'?
If so, do let me know.
Thanks!

Posted by jpeters on Jan. 29 2008,06:42
Quote (lucky13 @ Jan. 29 2008,00:04)
What did you link? I haven't used your extension, but it should overlay /usr leveraging unionfs. If you added links from /opt to those locations it's still overwriting /usr. No?

Edit: And if it's overwriting /usr, is it doing it now via unionfs or RAM as a dsl would?

I don't think it's overwriting anything; I added link "vim" to /usr/local/share.  That solved the issue.  


< http://jpeters.net/apps/vim_7.1.uci >

Quote

Personally, I think recompiling is the best way to solve the problem, since it not only eliminates the manual work of making symlinks, etc, it also saves you the trouble of making a 'user.tar.gz' file with the data files (e.g. help-menu files, spellcheck files) that are in '/usr/local/share/vim/vim71/'.


Actually, I simply used a wrapper, which checks to see if there's a link, if not adds it  A wrapper is frequently needed with UCI's anyway, such as for exporting paths to libraries.

Posted by ^thehatsrule^ on Jan. 29 2008,07:34
Quote
I added link "vim" to /usr/local/share.
Unfortunately, that doesn't count as a valid .uci according to the standard.  Although it may work, it will cause mkwriteable to be invoked (unless that has changed recently)

Quote
A wrapper is frequently needed with UCI's anyway, such as for exporting paths to libraries.
It's different because you are changing a restricted part of the filesystem.. for the same reason (above).

Posted by jpeters on Jan. 29 2008,08:22
Quote (^thehatsrule^ @ Jan. 29 2008,02:34)
Quote
I added link "vim" to /usr/local/share.
Unfortunately, that doesn't count as a valid .uci according to the standard.  Although it may work, it will cause mkwriteable to be invoked (unless that has changed recently)

Okay, so I'm guessing recompiling with --prefix=/opt/vim_7.1 will get all the paths into the /opt directory.  A few more weeks on the DSL board should prepare me for taking the California bar exam  :)

edit: I wasn't referring to gin & tonics

Posted by mikshaw on Jan. 29 2008,13:48
Quote
Okay, so I'm guessing recompiling with --prefix=/opt/vim_7.1 will get all the paths into the /opt directory.
Unless the process has changed since 6.x, that should work just fine. The existing vim.uci was built that way.

Posted by lucky13 on Jan. 29 2008,17:51
Quote
Okay, so I'm guessing recompiling with --prefix=/opt/vim_7.1 will get all the paths into the /opt directory.

Yes, vim compiles very nicely there with no need for wrapper scripts. Are you going to add the patches (242 as of this moment)?

Posted by jpeters on Jan. 29 2008,18:57
Quote (lucky13 @ Jan. 29 2008,12:51)
Quote
Okay, so I'm guessing recompiling with --prefix=/opt/vim_7.1 will get all the paths into the /opt directory.

Yes, vim compiles very nicely there with no need for wrapper scripts. Are you going to add the patches (242 as of this moment)?

Sounds like you have it going already, so won't bother.  Isn't  the source getting updated with the patches?

Perhaps a vim update for the next release? Probably the help menu and spellcheck aren't needed  (to cut down on size), but the visual features certainly are....Mikshaw's version would be a good model.

Posted by lucky13 on Jan. 29 2008,19:43
Quote
Isn't  the source getting updated with the patches?

No, it's manual afaik. And from looking through the patch directory it looks like there can be over 500 between versions.

Posted by jpeters on Jan. 29 2008,20:52
Quote (lucky13 @ Jan. 29 2008,14:43)
Quote
Isn't  the source getting updated with the patches?

No, it's manual afaik. And from looking through the patch directory it looks like there can be over 500 between versions.

Sisyphus
Posted by mikshaw on Jan. 30 2008,02:18
I've never quite understood the process of applying multiple patches to the source. I've run a single patch occasionally, but the idea of running 500 seems to be a bit crazy. I assume that process can be automated?
Posted by lucky13 on Jan. 30 2008,17:22
Quote
I assume that process can be automated?

Of course. The recommended process at vim is to concatenate the patches into one patch and then apply it. Ports systems (such as in FreeBSD) run scripts to download source and patches, apply patches, then compile and install.

There are a couple other options for vim. The version in CVS is the patched version. So if anyone using CVS wants to build vim-7.1.uci, have at it. The other experimental option uses aap, which is similar to building ports. I want to look at this a little closer at this to see if it can be leveraged for compiling UCIs.
< http://www.a-a-p.org/ports.html >

Posted by jpeters on Jan. 30 2008,18:21
Quote (lucky13 @ Jan. 30 2008,12:22)
Quote
I assume that process can be automated?

Of course. The recommended process at vim is to concatenate the patches into one patch and then apply it. Ports systems (such as in FreeBSD) run scripts to download source and patches, apply patches, then compile and install.

There are a couple other options for vim. The version in CVS is the patched version. So if anyone using CVS wants to build vim-7.1.uci, have at it. The other experimental option uses aap, which is similar to building ports. I want to look at this a little closer at this to see if it can be leveraged for compiling UCIs.
< http://www.a-a-p.org/ports.html >

I also figured there was some 'bs' in the implication that you were actually going through 500 patches, one by one.
Posted by lucky13 on Jan. 30 2008,23:42
Quote
I also figured there was some 'bs' in the implication that you were actually going through 500 patches, one by one.

No, 242. And not one by one. Re-read my first reply in this thread. I took the patched source from my FreeBSD partition (circa September or October), edited Makefile, compiled for Linux with prefix=/opt/vim. Here: "the beauty of FreeBSD ports -- I got every available patch."

That's what I'll do again -- use what I already have to reduce the work load. Just takes me a couple commands to do it. That's why I offered. Let me know if you change your mind and want to do it yourself your way.

The "500" was between 6.2 and 6.3; over 400 between 6.1 and 6.2 -- scroll to the end of the link below and look at the last of the 6.2 patches. The only point with that is, it could be many more patches before Bram releases vim 7.2, or it could be sooner than later. Some of those patches are for things I don't consider trivial or minor -- memory leaks, bad behavior.
< ftp://ftp.vim.org/pub/vim/patches/ >

Posted by mikshaw on Jan. 31 2008,00:27
Quote (lucky13 @ Jan. 29 2008,14:43)
Quote
Isn't  the source getting updated with the patches?

No, it's manual afaik. And from looking through the patch directory it looks like there can be over 500 between versions.

This is something I had never considered, not only with Vim but with all extensions I've built. It always seemed to me that official stable releases *should* at least update source releases with security and bug-fix patches, but I guess that was an incorrect assumption.
Posted by lucky13 on Jan. 31 2008,03:35
Quote
This is something I had never considered, not only with Vim but with all extensions I've built. It always seemed to me that official stable releases *should* at least update source releases with security and bug-fix patches, but I guess that was an incorrect assumption.

You can find what the vim patch level is with --version. Right now I'm using Knoppix/Debian (mix of Etch and Sid).
Code Sample
VIM - Vi IMproved 7.0 (2006 May 7, compiled Oct 10 2006 00:14:41)
Included patches: 1-122


Versioning can be kind of stupid and arbitrary sometimes, but it should be a static representation of development -- just a snapshot -- rather than one version continually being changed without anything explaining the difference between 3.1 released last week and 3.1 released this week. If each version were periodically patched or otherwise improved (or at least "changed"), shouldn't it get a new version number so developers and users could monitor any changes?

Posted by jpeters on Feb. 01 2008,00:38
Quote (lucky13 @ Jan. 30 2008,18:42)
Quote
I also figured there was some 'bs' in the implication that you were actually going through 500 patches, one by one.

No, 242. And not one by one. Re-read my first reply in this thread. I took the patched source from my FreeBSD partition (circa September or October), edited Makefile, compiled for Linux with prefix=/opt/vim. Here: "the beauty of FreeBSD ports -- I got every available patch."

I attempted it with aap (just to see if it worked)...aap installed okay, but told me the patches file was "unavailable" (!); meanwhile, I patched anything with "memory leak" in the notes for my own use (once they're downloaded, it goes fairly quickly).

Also, using './configure --prefix=/opt/vim_7.1' didn't stop it from looking in the usr dir for help and spellcheck files.

Posted by jpeters on Feb. 09 2008,19:13
Deleted:  thought I got prefix to self-contain spell-check, but didn't.

I did get AAP  to install all the fixes, however. It is now downloading ver. 7.1.244 .

Posted by jpeters on Feb. 10 2008,18:02
Okay, this seems to be working. This version includes all the patches and
is self contained with help & spellcheck; also includes gvim.

< http://www.jpeters.net/apps/vim_7.1.244.uci >

Posted by lucky13 on Feb. 12 2008,03:16
Did you use the python UCI for AAP?
Posted by jpeters on Feb. 12 2008,06:20
Quote (lucky13 @ Feb. 11 2008,22:16)
Did you use the python UCI for AAP?

Yes, I think I used 2.3.uci
Posted by lucky13 on June 06 2008,14:23
Reviving this since it's about vim-xxx.uci...

Mainly @jpeters if he's interested, anyone else either way.

These are the patches issued since the version of vim currently/still in testing. I put an asterisk next to things that may justify updating it. Column with 7.1.xxx is patch number.

* 2767  7.1.245  pressing CTRL-\ three times causes Vim to quit
 2739  7.1.246  configure hangs when the man pager is something strange
 6028  7.1.247  Netbeans: backspacing in Insert mode may skip a character
* 3691  7.1.248  can't set the '" mark; can't know if setpos() was successful
* 2144  7.1.249  after "U" the cursor can be past end of line
* 1684  7.1.250  error for ":setglobal fenc=anything" when 'modifiable' is off
* 3134  7.1.251  accessing freed memory when spell checking enabled
* 1399  7.1.252  (after 7.1.243) test 39 fails when locale uses utf-8 encoding
* 1751  7.1.253  ":sort" doesn't work in a one line file
 1894  7.1.254  Tests 49 and 55 fail when the locale is French
 1514  7.1.255  Vim doesn't support utf-32
*50921  7.1.256  findfile() also returns directories
 3326  7.1.257  configure can't always find the Tcl header files
* 3360  7.1.258  crash when doing "d/\n/e" and 'virtualedit' is "all"
* 1944  7.1.259  cursor in wrong place with 'rl', "utf-8" and illegal byte
* 1805  7.1.260  cursor position wrong after ^@ wrapping halfway if using utf-8
 2255  7.1.261  for a 2 byte BOM UCS-2 is used, which doesn't work for UTF-16
* 3438  7.1.262  can't get the process ID of Vim
* 2442  7.1.263  filetype with dot doesn't work for indent plugins
* 6295  7.1.264  crash when C-indenting
* 1310  7.1.265  hang when completing file name and space in 'isfname'
* 2510  7.1.266  version string returned by terminal may be used as typed input
* 1957  7.1.267  when changing folds cursor may be positioned in a wrong place
* 1576  7.1.268  always shows "+" at end of screen line with 'cursurline'
 6183  7.1.269  matchparen plugin has an arbitrary line number limit
* 2861  7.1.270  ":?foo?" matches in current line since patch 7.1.025
 1582  7.1.271  in tiny version ":!touch %" causes curbuf to be wrong
* 2334  7.1.272  buffer name [Location List] not used for buffer in other tab
* 2504  7.1.273  when profiling on Linux Vim exits early
 1549  7.1.274  (after 7.1.272) compiler warning with optimized build
40835  7.1.275  (extra) Mac: ATSUI and 'antialias' don't work together
 4946  7.1.276  "gw" uses 'formatexpr', even though the docs say it doesn't
* 2802  7.1.277  default for 'paragraphs' misses some items
 1989  7.1.278  (extra, after 7.1.275) build problem
* 3848  7.1.279  when using cscope temporary files are left behind
 1556  7.1.280  (after 7.1.275) Mac: build problems without multibyte feature
*  2094  7.1.281  (after 7.1.279) Vim hangs when cscope doesn't exit
16302  7.1.282  (extra) Win64: Installing context menu, compiler warnings
 7633  7.1.283  non-extra part of 7.1.282
 2258  7.1.284  compiler warnings for functions without prototype
 5787  7.1.285  (extra) Mac: dialog hotkeys don't work
* 2045  7.1.286  (after 7.1.103) "w" at end of buffer moves cursor too far
* 1859  7.1.287  crash when reversing a list after using it
* 3182  7.1.288  (after 7.1.281) cscope leaves behind temp files with gvim
* 1979  7.1.289  when EXITFREE is defined and 'acd' is set freed memory is used
* 2146  7.1.290  reading unwritten bytes when spell checking with large indent
 1940  7.1.291  compiler warning for int-long conversion
* 6698  7.1.292  when using a pattern with "\@<=" the submatches can be wrong
* 3087  7.1.293  spell checking considers super/subscript chars as word chars
* 2336  7.1.294  leaking memory when executing a shell command
* 6102  7.1.295  vimtutor only works with vim, not gvim
 9374  7.1.296  SELinux is not supported
* 1855  7.1.297  wrong parenmatch highlighting after search/replace dialog
 1558  7.1.298  src/gvimtutor is not distributed
* 9490  7.1.299  filetype detection fails for file name with special characters
* 1959  7.1.300  value of asmsyntax argument isn't checked for valid characters
* 1673  7.1.301  "File/Save" menu in Insert mode doesn't update tab page label
 1485  7.1.302  (after 7.1.299) compilation error on MS-Windows
 1409  7.1.303  (after 7.1.302) compilation error on MS-Windows, again
12135  7.1.304  shortpath_for_invalid_fname() is too complex and wrong
* 4735  7.1.305  can't edit compressed file with special characters in the name
* 2153  7.1.306  some Unicode symbol chars are handled like word chars
*23714  7.1.307  many warnings when compiling with Python 2.5
* 2673  7.1.308  when in readonly mode ":options" produces an error
 3989  7.1.309  installing and testing with a shadow directory doesn't work
* 8024  7.1.310  incomplete utf-8 byte sequence at end of the file not detected
* 2547  7.1.311  compiler warning for missing sentinel in X code

I've been keeping vim patched weekly on DSL hard drive via SVN (thanks Juanito!) after trying aap once to see if I'd want to try to write "recipes" to use it with other things (nope -- I'll stick with CVS/SVN). If there's interest in an update and jpeters doesn't care to do it, I can try to get it submitted this weekend along with other stuff on my to do list.
< http://lucky13linux.files.wordpress.com/2008....536.png >

Posted by jpeters on June 07 2008,21:18
go for it; vim is getting far beyond what I actually need (I've been playing with geany for a while).
Powered by Ikonboard 3.1.2a
Ikonboard © 2001 Jarvis Entertainment Group, Inc.