LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 02-09-2017, 03:44 PM   #16
GazL
LQ Guru
 
Registered: May 2008
Posts: 5,035
Blog Entries: 16

Rep: Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657

Interesting, mine doesn't set TERMCAP. Maybe the difference is down to the newer version of xterm in current.
 
Old 02-09-2017, 08:04 PM   #17
Xsane
Member
 
Registered: Jan 2014
Posts: 150

Rep: Reputation: 112Reputation: 112
Quote:
Originally Posted by GazL View Post
Interesting, mine doesn't set TERMCAP. Maybe the difference is down to the newer version of xterm in current.
Changelog:
Sat Dec 24 02:36:05 UTC 2016
l/libtermcap-1.2.3-x86_64-7.txz: Removed.
Replaced by equivalent functionality in the ncurses package.

This is going to make some noticable changes. xterm will certainly change.
This will fix the long standing issue with backspace and Delete. Of course, as
this thread points out, 'stty sane' will clobber backspace now. I wonder why
he left the /etc/termcap* files? Unless Pat thinks "Replaced by equivalent
functionality" means that termcap will still be used. Clearly you've shown
that it's not. If $TERMCAP isn't set, that means xterm was built against terminfo.
 
Old 02-10-2017, 03:31 AM   #18
GazL
LQ Guru
 
Registered: May 2008
Posts: 5,035
Blog Entries: 16

Rep: Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657
Quote:
Originally Posted by Xsane View Post
I wonder why he left the /etc/termcap* files?
Just in case of any old programs statically linked against libtermcap.a at a guess, though I do wonder if we really need the cut down termcap-linux file any more. Perhaps it would be better to just ship the termcap-bsd file as /etc/termcap?

xfce4-terminal still uses the wrong backspace character when left on the default 'auto-detected' setting, or alternatively sets the wrong $TERM depending on your point of view. Similarly 'rxvt' does the same by default, Not that I use either of them.
 
Old 02-10-2017, 04:19 AM   #19
GazL
LQ Guru
 
Registered: May 2008
Posts: 5,035
Blog Entries: 16

Rep: Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657
BTW, here's a ncurses program I wrote as a learning exercise and which shows the problem in action:

Oh, and here's a nice way of restoring terminal state at the end of a bash-script which is much safer than doing a tty sane:
Code:
#!/bin/bash

# Restore tty state on exit:
restore_tty() {
  stty -F /dev/tty $saved_tty_state
  echo "$(tput sgr0)Cleanup: tty state restored"
}
saved_tty_state=$(stty -F /dev/tty -g)

trap restore_tty EXIT

# main:

echo "turning off echo"
stty -F /dev/tty -echo 
echo "$(tput setaf 3)$(tput bold)Enter a password: "
read

echo "Oops we forgot to restore both colour and tty echo..."
echo "... but it doesn't matter because the trap wil save us!"

exit 0

Last edited by GazL; 12-02-2017 at 02:10 PM.
 
1 members found this post helpful.
Old 02-10-2017, 03:32 PM   #20
slalik
Member
 
Registered: Nov 2014
Location: Moscow, Russia
Distribution: Slackware
Posts: 165

Original Poster
Rep: Reputation: 118Reputation: 118
From the above discussion, I think that for me for 14.2 the best solution will be to use /etc/termcap from the xterm source with one customization at the very end of the file:
Code:
# Customization begins here.
[skip]
# This fragment is for people who cannot agree on what the backspace key
# should send.
xterm+kbs|fragment for backspace key:\
        :kb=\177:
(in the original file it was :kb=^H: ).
 
Old 02-10-2017, 08:26 PM   #21
GazL
LQ Guru
 
Registered: May 2008
Posts: 5,035
Blog Entries: 16

Rep: Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657
Quote:
Originally Posted by slalik View Post
From the above discussion, I think that for me for 14.2 the best solution will be to use /etc/termcap from the xterm source with one customization at the very end of the file:
Code:
# Customization begins here.
[skip]
# This fragment is for people who cannot agree on what the backspace key
# should send.
xterm+kbs|fragment for backspace key:\
        :kb=\177:
(in the original file it was :kb=^H: ).
Well, that's already been done on current (not for termcap, but in terminfo, and hopefully nothing is using termcap any more given that the library has been removed). But it's not used by all of the xterm definitions. There's a 'xterm-utf8' terminfo entry that seems to work well and uses kbs=\177 (from xterm+kbs). I've been playing with it tonight.

I've attached the Xresources needed to make it all work. I save it in /usr/local/share/X11/xresources/xterm-console.xrdb and then #include it in my ~/.Xresources

Last edited by GazL; 12-02-2017 at 02:10 PM.
 
Old 02-12-2017, 03:46 PM   #22
Xsane
Member
 
Registered: Jan 2014
Posts: 150

Rep: Reputation: 112Reputation: 112
Quote:
Originally Posted by GazL View Post
xfce4-terminal still uses the wrong backspace character when left on the
default 'auto-detected' setting, or alternatively sets the wrong $TERM
depending on your point of view. Similarly 'rxvt' does the same by
default, Not that I use either of them.
By 'wrong' I assume you mean ^?. I wish I had current installed to test
this. I wonder where they are getting it from. What happens to them if
you remove /etc/termcap?

Quote:
Originally Posted by GazL View Post
There's a 'xterm-utf8' terminfo entry that seems to work well and
uses kbs=\177 (from xterm+kbs).
This looks like a configuration mistake. Current's ncurses.SlackBuild
adds a new configuration option --with-xterm-kbs=DEL. To me this implies
a goal of duplicating the old /etc/termcap-Linux behavior having xterm
use ^? for backspace and perhaps is the reason Pat removed libtermcap.
But at line 187 the slackbuild overlays the terminfo DB created by
ncurces with a 10 year old terminfo that uses kbs=^H; this terminfo
source file does not have an xterm-utf8 stanza leaving the ncurses
version with kbs=\177.

Again, the ncurses.Slackbuild first patches ncurses with a file created
by Thomas E. Dickey in 2016 including changing 298 lines in
terminfo.src. It builds the terminfo DB with the --with-xterm-kbs=DEL
option so all xterms will use ^? for backspace; then it overlays the DB
with a Thomas E. Dickey xterm terminfo from 2007 that changes around 70%
of them back to using ^H.

If the goal is for xterm to use ^?, then I would say two things should
be changed.

1) remove $CWD/xterm.terminfo from line 188 of ncurses.Slackbuild.

and

2) use --enable-backarrow-is-erase configuration option for xterm.

The second will make xterm honor the terminfo entry for its backspace
key binding, instead of using its default ^H. Then the backspace key
will work in places that don't map H^ to 'erase' like readline(3) does.
For example shell scripts using 'read' and/or 'select'. An easy check is
using backspace in tzselect.

Last edited by Xsane; 02-12-2017 at 06:47 PM. Reason: a better solution for 2)
 
Old 02-12-2017, 05:32 PM   #23
GazL
LQ Guru
 
Registered: May 2008
Posts: 5,035
Blog Entries: 16

Rep: Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657
Thanks xsane, there's certainly a lot of shenanigans going on in that slackbuild.

According to this page on Thomas' site, xterm provides its own terminfo and termcap entry files. I'm guessing those are the ones you found in the ncurses slackbuild directory (though it looks seriously out of date). I assume Pat put them there rather than in the xterm package.

I also noticed that the xterm-utf8 entry I'd started using isn't defined in those files, so it's one that's coming from ncurses itself and not xterm. Which is probably why it's using the xterm+kbs fragment, which in turn is being set to ^? by the --with-kbs=DEL option Pat is using on the configure (which I'm not entirely convinced about being the right choice).

It's all becoming a little clearer, though I'm still a little concerned that different distro's may decide to use different --with-kbs= values, making the whole idea of terminfo definitions a bit of a mockery, so I'll probably switch back to using one of the ones Thomas provides for xterm.

As for termcap. As far as I understand it, it's not used if the library can find an entry of the same name in the terminfo database. If it isn't found, then ncurses will dynamically generate a terminfo entry from the termcap and store it in ~/.terminfo for future use.

Last edited by GazL; 02-12-2017 at 06:31 PM.
 
Old 02-12-2017, 08:01 PM   #24
Xsane
Member
 
Registered: Jan 2014
Posts: 150

Rep: Reputation: 112Reputation: 112
Quote:
Originally Posted by GazL View Post
According to this page
on Thomas' site, xterm provides its own terminfo and termcap entry
files. I'm guessing those are the ones ...
Yes, both are in xterms source. That may be where the old xterm.terminfo
file came from.

Quote:
Originally Posted by GazL View Post
I assume Pat put them there rather than in the xterm
package.
I don't know why he did that. The same person (xterm's author) is
maintaining both xterm's terminfo and ncurses misc/terminfo.src. You'd
think that they would be compatible.

Quote:
Originally Posted by GazL View Post
I also noticed that the xterm-utf8 entry I'd started using isn't defined
in those files, so it's one that's coming from ncurses itself and not
xterm. Which is probably why it's using the xterm+kbs fragment, which in
turn is being set to ^?
Yes, that's right. As I said:
Quote:
... this terminfo source file does not have an xterm-utf8 stanza leaving
the ncurses version with kbs=\177.
There are around 21 stanza's that are not clobbered by the
xterm.terminfo at line 188 of ncurses.SlackBuild. Of course not all of
them have a kbs="" entry.

Quote:
Originally Posted by GazL View Post
the --with-kbs=DEL option Pat is using on the configure (which I'm
not entirely convinced about being the right choice).
There really isn't a perfect choice to make between 8 or 127 for the
backspace key. Either choice will break something. I lean toward using 8
because it is POSIX and it makes sense to distinguish between backspace
and delete. On the other hand I get why a Linux distro would want to
match the linux console.

BTW the option is specific to xterm: --with-xterm-kbs

Quote:
Originally Posted by GazL View Post
It's all becoming a little clearer, though I'm still a little concerned
that different distro's may decide to use different --with-kbs= values,
making the whole idea of terminfo definitions a bit of a mockery, so
I'll probably switch back to using one of the ones Thomas provides for
xterm.
I don't think it's a mockery as long as the vt's follow them (which
unfortunately xterm doesn't by default. Well, to be complete, it's
display side does and its input side doesn't; which seems counter
intuitive to me). It's okay to customize the DB's. I think that is part of
the concept of having them. I certainly understand you wanting backspace
to be the other way though. For me it's not a big deal which is chosen;
it is a big deal that the choice actually works though. In my opinion
it's been broken for a very long time.

Quote:
Originally Posted by GazL View Post
As for termcap. As far as I understand it, it's not used if the library
can find an entry of the same name in the terminfo database. If it
isn't found, then ncurses will dynamically generate a terminfo entry
from the termcap and store it in ~/.terminfo for future use.
It depends on the app. For xterm it's compiled in to use one or the
other. It seems like I ran across one vt that hardcodes the backspace
key mapping.

Note: I changed part two 2) of the suggested fix in my previous post.
It's a much better solution.

Last edited by Xsane; 02-12-2017 at 08:11 PM. Reason: typo
 
Old 02-13-2017, 06:47 AM   #25
GazL
LQ Guru
 
Registered: May 2008
Posts: 5,035
Blog Entries: 16

Rep: Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657
Quote:
Originally Posted by Xsane View Post
Yes, that's right. As I said:
Yes, I apologise if I didn't quite take it all in, I'm suffering information overload on this topic, and was getting confused by the replacing of definitions with older ones tht Pat is doing in the slackbuild (which I admittedly missed).

Quote:
Originally Posted by Xsane View Post
I don't think it's a mockery as long as the vt's follow them (which
unfortunately xterm doesn't by default. Well, to be complete, it's
display side does and its input side doesn't; which seems counter
intuitive to me). It's okay to customize the DB's. I think that is part of
the concept of having them. I certainly understand you wanting backspace
to be the other way though. For me it's not a big deal which is chosen;
it is a big deal that the choice actually works though. In my opinion
it's been broken for a very long time.
Just to be clear here. I don't want backarrow to send DEL, that's not my goal. I don't care what it sends as long as it matches the kbs= so that ncurses programs recognise it correctly and that stty erase is set appropriately so that tty input works correctly outside of readline (which adds its own translations into the mix). Though like you, I do tend towards it sending ^H because that is what it has historically done and is POSIXish.

Let's look at the default setup for xterm
ptyInitialErase: false - means that stty erase gets set to whatever the kbs= is.
backarrowKeyIsErase: false - means that the backarrow key will be set by the backarrowKey resource, regardless of what the erase was set to from the terminfo entry.
backarrowKey: true - It gets set to ^H.

Now this is a sensible default setup: an xterm will always act the same way and as long as any terminfo entries are written to reflect what xterm does by default everything is dandy. But here comes --with-xterm-kbs=DEL and now any terminfo entry that derives from the 'xterm+kbs' fragment because of a 'use=' is tainted. 'xterm-utf8' is currently such a definition on slackware.

Try starting a xterm with xterm -xrm "XTerm.termName: xterm-utf8" on a unmodified install of slackware-current and you'll get:
Code:
browser@ws1:~$ echo $TERM
xterm-utf8
browser@ws1:~$ stty -a
speed 38400 baud; rows 18; columns 135; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z
;
rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc
browser@ws1:~$ infocmp | grep 'kbs='
        kbs=\177, kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC,
browser@ws1:~$ od -tx1c
^H
0000000  08  0a
         \b  \n
0000002
Erase gets set to ^? because of what's in the terminfo definition and any ncurses applications testing for KEY_BACKSPACE aren't going to work correctly as xterm itself is still generating a ^H when the backarrow key is being pressed.

Ok, there's an easy solution to that if you're prepared to change how xterm behaves: you set backarrowKeyIsErase: true, and now xterm will correctly generate a ^? because it's setting it from the stty erase value, which it set from the kbs= value. But what happens if I ssh to a host that has ncurses built without --with-xterm-kbs=DEL? It's kbs= value for this terminfo entry is going to be ^H and we're back to the key not being detected properly again in ncurses applications. backarrowKeyIsErase only fixes things locally. This is why I think --with-xterm-kbs=DEL is a mistake. IMO it would be better to ship ncurses without that configure option and leave the xterm+kbs value in its default state.

Now, the reason we don't have this problem when the default of TERM=xterm is used is that Pat is using that terminfo definition file from 2007 which doesn't derive from xterm+kbs. if you look at the latest definitions on Thomas' site you'll see that his 'xterm' derives from xterm-new which derives from xterm-basic which derives from xterm+kbs and if we were using those then we'd see the same thing for 'xterm' as we do for 'xterm-utf8'

My thoughts on this are that we should not be setting that --with option when building ncurses and should be using the latest definitions from Thomas and not the ones from 2007. And hopefully that will mean that xterm in its default configuration will work consistently across any distro that haven't messed with those defaults.

What we have now just feel really ugly. I think I'll try rebuilding ncurses as I describe above and see what happens.

Last edited by GazL; 02-13-2017 at 06:49 AM.
 
2 members found this post helpful.
Old 02-13-2017, 03:27 PM   #26
Xsane
Member
 
Registered: Jan 2014
Posts: 150

Rep: Reputation: 112Reputation: 112
Quote:
Originally Posted by GazL View Post
Now this is a sensible default setup: an xterm will always act the same
way and as long as any terminfo entries are written to reflect what
xterm does by default everything is dandy.
It's functional, I'm not sure I'd call it sensible. You're saying
terminfo must kowtow to xterm's default key mapping. xterm honors
terminfo/termcap for it's display side but ignores it on its input side.
It seems more sensible to have both sides honor the DBs. Which
'XTerm*backarrowKeyIsErase: true' makes it do. Then things work no
matter which kbs value is in terminfo.

Quote:
Originally Posted by GazL View Post
But here comes --with-xterm-kbs=DEL and now any terminfo entry
that derives from the 'xterm+kbs' fragment because of a 'use=' is
tainted. 'xterm-utf8' is currently such a definition on slackware.
The option makes any xterm stanza that sets kbs use ^? for backspace. As
long as we don't randomly clobber some of them with xterm.terminfo, and
xterm honors the DB for the backspace key mapping, everything should be
fine. By calling the utf8 stanza 'tainted' it seems like you are
speaking from the position that Pat doesn't intend for backspace to be
^?. Since he added the option that does exactly that, I think it is his
intention, but the old xterm.terminfo file applied later was overlooked.


Quote:
Originally Posted by GazL View Post
But what happens if I ssh to a host that has ncurses built without
--with-xterm-kbs=DEL? It's kbs= value for this terminfo entry is going
to be ^H and we're back to the key not being detected properly again in
ncurses applications. backarrowKeyIsErase only fixes things locally.
This is why I think --with-xterm-kbs=DEL is a mistake. IMO it would be
better to ship ncurses without that configure option and leave the
xterm+kbs value in its default state.
I'm not an ssh guru, my impression is that it's supposed to behave as
though you were logged in locally. So shouldn't the remote terminal be
handling input key mapping? If it's as you say, then perhaps that is the
reason that the Control key toggles the values for backspace; to make it
easy when logging in remotely. I mean, you can do whatifs all day, what
if we configured locally to use ^H and the remote is using ^?

Quote:
Originally Posted by GazL View Post
Now, the reason we don't have this problem when the default of
TERM=xterm is used is that Pat is using that terminfo definition file
from 2007 which doesn't derive from xterm+kbs. if you look at
the latest
definitions on Thomas' site
you'll see that his 'xterm' derives
from xterm-new which derives from xterm-basic which derives from
xterm+kbs and if we were using those then we'd see the same thing for
'xterm' as we do for 'xterm-utf8'
I don't think so. Because its use at line 188 of ncurses.SlackBuild is
unaffected by --with-xterm-kbs. So the result would be the same;
applying xterm.terminfo mostly reverses the results of --with-xterm-kbs
and should not be done if Pat wants xterm to use ^? for backspace.

Quote:
Originally Posted by GazL View Post
My thoughts on this are that we should not be setting that --with option
when building ncurses and should be using the latest definitions from
Thomas and not the ones from 2007. And hopefully that will mean that
xterm in its default configuration will work consistently across any
distro that haven't messed with those defaults.
Now we are getting into: what character should the backspace key be
mapped to? Maybe that is my fault, I did say that I didn't think that
there is a perfect solution between the two choices.

I have a feeling that this as been argued for long time, probably with a
few flame wars along the way. I'm guessing that Pat's opinion is well
entrenched and it seems to be that 'backspace == ^?' That has been
xterm's configuration historically in Slackware by using
/etc/termcap-Linux. So my comments here are mostly to reach that end,
that is, configuring for backspace to be ^?.

So just in case Pat is reading this I'll offer my opinion again using a
little different wording:

The ncuses' --with-xterm-kbs configuration option goes hand-in-hand with xterm's
--enable-backarrow-is-erase configuration option.

Applying xterm.terminfo is at odds with --with-xterm-kbs and mostly
undoes its effects. Every stanza in xterm.terminfo is already in
ncurses-6.0/misc/terminfo.src. I haven't checked, but I would expect
them to be comparable. Unless there is some secret sauce in
xterm.terminfo it should not be needed.
 
Old 02-13-2017, 04:36 PM   #27
GazL
LQ Guru
 
Registered: May 2008
Posts: 5,035
Blog Entries: 16

Rep: Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657
I think it boils down to a philosophical point of view. The idea behind terminfo/termcap entries are that they describe the capabilities, characteristics and features of a terminal to applications. With both ptyInitialErase: false and backarrowKeyIsErase: true set for xterm, the terminfo entry has been promoted from a purely passive description to an active configuration file, and while I can see the advantages to that, it feel like scope-creep.


Anyway, I've rebuilt ncurses, dropping the --with-xterm-kbs option, and using the latest xterm.terminfo from xterm-327.tar.gz instead of the one from 2007. I've also removed the extra rxvt, screen and ETerm files which date back to 2001,2002,2003, and I've fixed the tmux one (tmux uses \177 for stty erase, but the ncurses supplied definition specifies ^H). I've also built a aaa_terminfo-6.0 package from the updated build as current is still shipping a 5.9 version and I wanted everything tidy.

Now, there's still the issue of "what value do other distro's use for --with-xterm-kbs?.. but unfortunately I suspect the answer to that is going to be that there's no consensus on that and they all vary.

Anyway, it feels cleaner like this so barring encountering any issues because of what I've done I'm happier with the situation. I'll see how it goes.


edit: And after all that, I put everything back to stock slackware as I decided I can't be bothered to parallel maintain all this stuff. Still, was an interesting exercise if nothing else.


edit2: And then I slept on it and this morning I changed my mind again as it still bothers me.

So, final situation... I've removed all the redefinitons for xterm, screen and ETerm entries from the slackbuild and rebuilt. I am just using what is provided by ncurses (including the development patches Pat was already applying). I've also removed the tmux.terminfo file from the tmux package as that is also included in the stock ncurses definitions. And like before I'm still not specifying --with-xterm-kbs and letting it default.

The kbs= value for the 'tmux' terminal entry provided by ncurses appears to be incorrect, as on linux at least, it uses ^? but the terminfo specifies ^H but I don't know whether fixing that is the right thing to do yet. I need to find out whether tmux on other systems also uses that character or whether it's just because linux ptys use ^? as erase by default. I need to get someone with a BSD to check perhaps.

1 final update:
After digging through the tmux source, I have discovered that tmux is indeed hard coded to set VERASE \177 using tcsetattr(). It's not in a config option or a #define, it's a hard coded constant in the source. So, for tmux terminfo entry kbs=\177 is the correct setting. I've knocked up a patch file and dropped it in the ncurses slackbuilds patches/ directory. If anyone wants it let me know.

Last edited by GazL; 02-14-2017 at 09:27 AM.
 
1 members found this post helpful.
Old 05-27-2017, 08:10 PM   #28
Xsane
Member
 
Registered: Jan 2014
Posts: 150

Rep: Reputation: 112Reputation: 112
ChangeLog:
Quote:
Wed May 24 04:51:46 UTC 2017
l/ncurses-6.0-x86_64-3.txz: Rebuilt.
Drop --with-xterm-kbs=DEL option, taking the upstream default of ^H.
Added a modified tmux terminfo, setting kbs=\177, as it expects.
Default to upstream versions of everything else in the terminfo database.
Thanks to Xsane and GazL for some insights on a more correct configuration.
 
1 members found this post helpful.
Old 05-28-2017, 04:22 AM   #29
GazL
LQ Guru
 
Registered: May 2008
Posts: 5,035
Blog Entries: 16

Rep: Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657Reputation: 2657
Quote:
Originally Posted by Xsane View Post
ChangeLog:
Yep. That's 3 packages I'm no longer having to parallel maintain.

Thanks Pat.
 
1 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
HOWTO: Initial Setup of slackrepo (plus some questions) bassmadrigal Slackware 98 09-17-2017 05:31 PM
slackrepo and custom SlackBuild atelszewski Slackware 4 11-01-2016 06:42 PM
[SOLVED] Two questions / wishes related to slackrepo slalik Slackware 3 07-21-2015 05:18 AM
[SOLVED] Running rc.local with additional routes produces SIOCADDRT file exists and bombs johnmchugh623 Debian 1 08-27-2010 07:38 AM
Backspace produces "^?" after upgrading to FC3 fearofcarpet Fedora 5 01-04-2005 01:54 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 05:59 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration