SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I just repackaged it (with 37 locales bundled, as usual). All I can say is it starts and seems to work[1]. Caveat: tested during less than 5 minutes Release notes System requirements (unchanged since 52.0)
[1]On Slint64-14.2 that has the same base packages as Slackware64-14.2
Last edited by Didier Spaier; 04-30-2017 at 04:43 PM.
lxc 2.0.7 with a new Slackware template and cgmanager is obsolete
I have modified the template lxc-slackware.in at the root of the source lxc directory of Slackware64 14.2 in such a way that it allows to build and run unprivileged as well as privileged containers, see this post.
Please note that both /etc/rc.d/{rc.cgconfig,rc.cgred} have to be executable, and r.cgconfig started first for unprivileged containers.
---
Also, cgmanager is not needed for that and I think that it could be removed or moved to /pasture. All that is needed is to rebuild ConsoleKit2 with cgmanager not installed. As far as I know cgmanager is not a dependency of another package shipped in Slackware (see the discussion in this thread).
PS: template slightly modified on 01/05/2016, 09:58 UTC+2
EDIT 03 May 2017: I forgot to upload the patch to lxc.SlackBuild proposed by Johannes Schöpfer (franzen @ LQ), see this post.
It is now in http://slint.fr/forSlackware/lxc/ too.
Last edited by Didier Spaier; 05-03-2017 at 08:02 AM.
Reason: EDIT added
If you want to use the ncurses version of vim on a terminal within X and still use the X selections you can add set mouse="" to your vimrc and then you can cut/paste into the terminal in the usual manner. You just have to remember to enter input mode before you paste. I got into the habit of doing it that way with elvis (which didn't have direct access to the X selections) and I still tend to do it with vim. It's not quite the same as using the "* and "+ to access the buffers, but if you're running in X anyway you might as well use gvim, which has them enabled.
There's value in shipping a version of vim that isn't dependent on X11 libraries for those that don't install X.
I never use gvim it's not an option since i work in konsole.
Setting 'set mouse=""' won't do anything since the support isn't compiled in.
Try "vim --version | grep clipboard" and you will see that the support isn't compiled in so you need to recompile it before 'set mouse=""' will work.
Without set mouse="" in .vim/vimrc pressing mouse button 2 will just paste whatever is already in vim's cut buffer.
With set mouse="" in .vim/vimrc pressing mouse button 2 doesn't do that. Instead the "X11 PRIMARY selection" is pasted. (note: not the same as the clipboard)
Vim doesn't need to access the X11 selection itself because the selection is actually being pasted by xterm. My assumption is that when you use any other mouse value, vim uses some sort of escape sequence to configure xterm not to paste when button 2 is pressed, but I don't know for certain, that's just a guess. From the xterm man-page:
Quote:
Xterm allows character-based applications to receive mouse events (currently button-press and release events, and button-motion events) as keyboard control sequences. See Xterm Control Sequences for details.
Anyway, if you're not seeing a difference then maybe konsole doesn't support the feature, but it certainly makes a difference on xterm.
edit:
see http://vimdoc.sourceforge.net/htmldo...tml#'mouse'
so... my reading of that is that setting mouse="" disables mouse support in vim which allows xterm to do it's normal mouse handling. It seems you can also allow xterm to do its thing by holding the shift key down while doing your mouse operations if you haven't disabled mouse support, which I didn't know, so I've just learnt something too.
see http://vimdoc.sourceforge.net/htmldo...tml#'mouse'
so... my reading of that is that setting mouse="" disables mouse support in vim which allows xterm to do it's normal mouse handling. It seems you can also allow xterm to do its thing by holding the shift key down while doing your mouse operations if you haven't disabled mouse support, which I didn't know, so I've just learnt something too.
Yes, this is a normal ncurses thing. If mouse support is enabled, you have to hold shift in order to select and copy text. It's the same way with mc and others, I'm sure.
Without set mouse="" in .vim/vimrc pressing mouse button 2 will just paste whatever is already in vim's cut buffer.
With set mouse="" in .vim/vimrc pressing mouse button 2 doesn't do that. Instead the "X11 PRIMARY selection" is pasted. (note: not the same as the clipboard)
Vim doesn't need to access the X11 selection itself because the selection is actually being pasted by xterm. My assumption is that when you use any other mouse value, vim uses some sort of escape sequence to configure xterm not to paste when button 2 is pressed, but I don't know for certain, that's just a guess. From the xterm man-page:
Anyway, if you're not seeing a difference then maybe konsole doesn't support the feature, but it certainly makes a difference on xterm.
edit:
see http://vimdoc.sourceforge.net/htmldo...tml#'mouse'
so... my reading of that is that setting mouse="" disables mouse support in vim which allows xterm to do it's normal mouse handling. It seems you can also allow xterm to do its thing by holding the shift key down while doing your mouse operations if you haven't disabled mouse support, which I didn't know, so I've just learnt something too.
The thing is that without --with-x there is no support for clipboard or xterm_clipboard.
If you check "vim --version" you will see that there's -clipboard and -xterm_clipboard that means that the support isn't compiled in.
Without this i can copy and paste between different vim sessions but i can't copy and paste from other programs like firefox.
It works with vi but not vim.
I had some time now so i looked a bit deeper into this and it turns out that configure says that --enable-gui=auto is default but it turns out that's wrong (bug?), so adding --enable-gui=auto to vim.SlackBuild fixes it.
The problem was that it doesn't enable gui.
Nice to see continued refinement of fontconfig in current. While we're on the subject, perhaps it's time to get rid of 'speedo'? I'm not sure there's even a way to use these any more.
I confess, though I usually view compiler releases with suspicion, the new "-fsanitize-address-use-after-scope" feature looks genuinely valuable. Compiling packages with this flag enabled could expose a lot of heretofore unknown bugs.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
