Hi Axel, hi Brian,
Since the current maintainer of screen in Debian is quite busy in real
life at the moment, I'm thinking about doing an Non-Maintainer Upload
(NMU) for screen. Your packaging work comes in quite handy there,
thanks! :-)
thanks to both of you for your work on getting the
Package: openafs-krb5
Severity: normal
Hi,
found while using aklog, so reporting against -krb5...
= src/auth/cellconfig.c:
] int
] afsconf_GetAfsdbInfo(char *acellName, char *aservice,
] struct afsconf_cell *acellInfo)
] {
] [...]
] code = afsconf_LookupServer((const
Hi,
found while using aklog, so reporting against -krb5...
This code doesn't exist in the current version of openafs in unstable or
testing, so I assume you're using the version from experimental?
oh right, forgot the tag (and the Version: header, sorry). It's the current
experimental
Hi,
probably an optimization problem? Given the test program
extern void g_type_init(void);
int main(int an, char **ac) {
(void)g_type_init();
return 0;
}
I get this backtrace:
#0 g_bsearch_array_create ()
at
.
+
+ -- Jan Christoph Nordholz he...@pool.math.tu-berlin.de Mon, 07 Sep 2009
23:01:50 +0200
+
pam-shield (0.9.2-3.1) unstable; urgency=low
* Non-maintainer upload.
diff -u pam-shield-0.9.2/debian/patches/automake.patch
pam-shield-0.9.2/debian/patches/automake.patch
--- pam-shield-0.9.2
Hi Marco,
it seems the kernel is at fault and not udev. Have a look at this commit,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8442edc18843491978f7820f87dbdf293461290e
especially the third blob - the unfixed version rounded even a
-name_len == 0 up to
Hi Marco,
I've seen this, too. I couldn't reproduce the hang-on-boot yet after
experiencing it once, but the segfaults are pretty reliable. Here's
an exemplary crash and the accompanying debug log (attached).
I'm away over the weekend, but I'll gladly help when I get back if
you need core dumps
tags 541349 + pending
clone 541349 -1
reassign -1 autofs5
kthxbye
Hi Petter,
Here is an updated patch. It occured to me that for systems using
LDAP (libnss-ldapd) instead of NIS, autofs should probably start after
the nslcd daemon too. This patch make sure it does.
thanks for collecting
Hi Thomas,
This one is hard to reproduce (here). valgrind is not showing me any
problems as I resize the screen in various ways.
There are several special cases in the resizing logic, depending on
resource-settings, as well as the amount of text that has been scrolled
off onto the
Hi Thomas,
Here's a fix for the positioning problem that I've been seeing (attached).
thank you very much, the malloc corruption is gone now, too.
Regards,
Jan
signature.asc
Description: Digital signature
Package: xterm
Version: 244-1
Severity: normal
Hi,
I just noticed that xterm doesn't like it very much to be resized: when I grab
a window edge and make a circular motion (i.e. enlarge and shrink again in
both dimensions), I usually get it to segfault within fractions of a second.
Here are a few
Hi Michael,
No idea. If I were knew, I'd attach a patch for this issue.
The code is quite.. funny and fragile, I tried to understand
it right before submitting a bugreport but that wasn't quite
successful.
I ran it under strace - pure automountd, without any startu
scripts but with the
Package: buildd.debian.org
Severity: wishlist
Tags: patch
Hi,
please mark the source packages autofs and autofs5 as Linux-specific.
Both could theoretically be adjusted to build on other architectures,
but the daemons are useless without the Linux autofs kernel module
anyway.
Best regards,
Hi,
Package: autofs5-ldap
Version: 5.0.4-1
Severity: normal
restarting automount gave a segfault (/var/log/syslog):
sorry that it took a while until I had time to prepare a new version
of the Debian package. Could you please confirm that the segfault
problem persists with 5.0.4-2? I cannot
Hi Stephane,
in screen-profiles preinst :
aah, thanks for the hint, I did not know that screen-profiles had entered
Debian and was diverting the screen binary. I'll check back how soon the
package will be replaced by byobu (cf. #531791) and whether it still makes
sense to change the screen init
Hi Dustin,
I had seen quite some time ago that the screen-profiles package had
entered Ubuntu, but I had no idea that it had made it to Debian in
the meantime and that it was diverting the binary. A notification
would have been great, as I've responded to the increasing number
of reports of
Hi Christoph,
sorry this has been lying around for so long - I'm just catching up on
all bug reports...
Maximize the terminal. The size of screen does not change, only the
area avaible before is used.
Sadly it does change here and always did. Do you still see that behaviour
with your terminal
Hi,
Sorry, I don't have an upgrade path. I only do the sporadic apt-get
upgrade and an apt-get dist-upgrade once in a blue moon. Sometimes
things don't work out and when I report that they just say upgrading
from xxx to yyy is not supported even though I have no intention to
nor would I have
Hi,
but I gat a similar message:
I've seen this happen for a couple of times now, yet there has never
been a single reproducible test case. But because I still hope I might
see one someday I don't want to swap those lines.
I've already documented screen's requirements regarding the permissions
Hi,
Not to be picky, but the label is unchanged on the 4.0.3-11 screen
package (the latest in current Debian testing).
have you tried to start screen in a small terminal (i.e. with 10 rows)?
The bottom line reads Press Space for next page or Return to end then,
and in this context it is
Hi.
I'm still looking for an upgrade path that reproduces this bug.
Up to 4.0.3-0.3 /var/run/screen was part of the package tarball
(and mode 0775 root:utmp), then it got moved out of it and its
creation postponed to the initscript (for volatile /var/run mounts)
or postinst - also root:utmp and
Hi Michael,
(the following holds for both autofs v4 and v5)
usually the daemon creates these directories on startup and removes
them on exit. If you do not want that to happen, it suffices to
mark the directory as u-w:
] r...@apocatequil:/etc# grep ^/misc /etc/auto.master
] /misc
Hi,
As I mentioned before, the ONLY way to stop it from
removing the top-level dir is to chattr+i it.
ah, autofs4 indeed removes the directory even without write permission
(v5 doesn't), I thought I'd checked that, too. But this behaviour has
been around for ages, and I still don't understand
Hi,
automount[18849]: cache_ghost: entry in file:/etc/auto.direct not valid map
format, key /...
It appears that someone was trying sanity tests (disallow /. and /..),
but didn't contemplate their being anything after /.. (like another .,
or any other character)...
Clearly, the length
tags 534732 = confirmed
thankyou
Hi again,
I can't reproduce that here with 1.81.6-7...
ok, I take that back, it does indeed produce strange expansions sometimes.
Will investigate.
Regards,
Jan
signature.asc
Description: Digital signature
Hi Jeffrey,
The expansion of numbered backups is incorrect. The actual expansion
that nvi produces is somewhat random. I get the weirdest results when
editing from the linux console, logged in as root. The expansion of
numbered backups used to work correctly with nvi 1.79 version.
I can't
Hi Emmanuel,
It would be nice if you could attach your patch to this bug report
even if it is not fully functionnal. It could help upstream developers
to add this feature more quickly.
ah, I see there has been another 0.2.6 release. I thought that branch
would die soon now that 0.3
Hi,
i think that the code you produced for 0.2.x branch could helped to
add this feature in one of the next release.
ah ok, I believed 0.3 was written (almost) from scratch, so I wasn't sure
whether there would be any benefit. I've attached my patch, but there are
a few remarks:
* The gnutls
Hi,
NMU is about to hit unstable and s-p-u. I've added the attached
patch to the quilt series.
Regards,
Jan
Add fix for CVE 2008-6792 and another related bug in do_get_use_md5().
-- James Westby james.wes...@canonical.com
-- Jan Christoph Nordholz he...@pool.math.tu-berlin.de
--- system
Hi,
Thanks Jan. Our current svn does not have an nselibs-bin directory
anyway. I've applied your patch to our configure.ac and regenerated
configure in our latest SVN.
All the better. SVN checkout works great here, too, system lua5.1 is
detected and linked into nmap instead of the internal
Hi,
Thanks Jan. But if you get a chance, I'd love to see a patch which
checks for both the plain lua and lua5.1 versions. That way it
would still work on platforms which just use plain lua and so it
would be appropriate for upstream integration. If we add it to an
Nmap release, Debian
Package: wpasupplicant
Version: 0.6.9-2
Severity: important
Tags: security
Hi,
your syslog patch changes _wpa_hexdump() to create the debug string in a
local buffer on the stack before emitting it - however you boldly assume
that 2048B should be enough for everyone. When connecting to a WPA-EAP
tags 527997 = patch
thankyou
I might as well attach the appropriate patch... (autoconf is called
from the upstream Makefile, which makes the build process a bit
cumbersome now that we're patching configure.ac - you might choose
to patch configure itself instead, or call autoconf early in the
Package: nmap
Severity: important
Hi,
nmap has an internal copy of liblua and uses it instead of the system library
because the configure script fails to detect the header files:
} (package build log)
] checking lua.h usability... no
] checking lua.h presence... no
] checking for lua.h... no
]
Hi,
while you're at it, there is another bug in that small perl
function: do_get_use_md5() recurses when it encounters an
'@include' line and overwrites its $use_md5 variable with
the result. Therefore the following /etc/pam.d/passwd would
make the function return 0:
requiredpam_unix.so
tags 526160 + patch
thankyou
Hi,
ksh is failing because libc0.1-dev does not provide TAB{0,1,2,3}, but
only TAB{0,3} (= bits/termios.h). As this seems to be intentional (see
http://www.freshports.org/sysutils/coreutils/ for the corresponding
changes to the BSD coreutils), ksh should probably
Hi,
this was a bug in libc0.1-dev, not in ksh itself, cf. #522686. ksh
simply needs to be rebuilt on kfreebsd-*.
Regards,
Jan
signature.asc
Description: Digital signature
tags 524211 + patch
thankyou
Hi,
attached is a patch that fixes the /usr/local problem and also
adjusts the build dependencies (libxaw7 is not necessary at all,
and libglib1.2-dev should be replaced by libglib2.0-dev).
A debhelper upgrade might be in order, too, but I didn't want
to be too
Christoph Nordholz he...@pool.math.tu-berlin.de 2009-04-13
+
+--- jobs.c.orig2009-01-29 23:09:49.0 +0100
jobs.c 2009-04-13 01:55:54.019583928 +0200
+@@ -134,6 +134,10 @@
+ #if !defined (WIFCONTINUED)
+ # define WIFCONTINUED(s) (0)
+ #endif
++#if defined(__FreeBSD_kernel__
Hi Axel,
screen on kfreebsd-i386 and kfreebsd-amd64 doesn't seem to pass any
signals (at least STOP, INT and WINCH) to text applications or shells
running inside that screen.
thanks for bringing the kfreebsd port to my attention. The buildd log
looks a bit suspicious, too.
I'll debug this,
Hi Axel,
There are DD accessible kfreebsd machines:
I'm well aware of that. But I don't have that status (yet). ;)
If you happen to know of other kfreebsd machines where I could get
temporary access, that would be great - otherwise I'll just get
that VM running, might come in handy to have one
retitle 474128 ITA: libdumbnet -- A dumb, portable networking library
owner 474128 !
kthxbye
Hi,
I'll take this one. Upstream's build system is quite straightforward
(once you've updated all those ancient autotools files), and getting
C networking code into shape is one of my favourite tasks
Hi Stefanos,
if you need help, I could lend a hand now and then. I don't have the
time to maintain the package on my own, but I have a faible for old
and/or undocumented C code and some experience in delving through
networking code in particular, so I could e.g. help hunting bugs.
Regards,
Jan
unarchive 407667
reopen 407667 !
found 407667 3.0.5-2
kthxbye
Hi,
when you brought the request list back in 3.0.5-2's debian/dhclient.conf,
the 'ntp-servers' parameter was again missing in it and still is. Would you
please add it to the list?
Thanks,
Jan
signature.asc
Description: Digital
tags 398752 + wontfix
close 399913
kthxbye
Hi,
as there's been no activity at all and as I'm on final consideration joining
Steve's opinion, I'm tagging my bug wontfix and closing the corresponding
policy bug again. Sorry for the noise, guys.
Regards,
Jan
signature.asc
Description: Digital
Hi Kevin,
For anybody who falls on this bug, PHP MUST BE disabled where hypermail
outputs its files, or i guess someone can hack you by sending php files
to the list and you will host those backdoors..!
how is this going to work? The first line that hypermail writes contains
?xml, and if
Hi,
ls -las /usr/bin/screen
328 -rwxr-sr-x 1 root utmp 328448 Mar 6 16:36 /usr/bin/screen
ok, then there are a couple of other reasons why this could be
the case. I've just added a new QA pair to the upcoming version
because there's often confusion about this:
Q: screen always complains
Hi Brian,
when I first start screen after the system boots, it refuses to start, with
a message that /var/run/screen must have permissoins 777. I chmod it, and
it runs.
I guess you removed all setid bits from /usr/bin/screen? The expected mode of
/var/run/screen depends on the setid bits
Hi Dustin,
thanks for the patches. I'm not satisfied with the fix for #323756 though:
It would suppress all errors of the 'source' command, even if a user expli-
citly does {^A:source nonexistent} - and I'd expect that to display a flashy
warning message if the file isn't there.
Regards,
Jan
severity 518245 minor
tags 518245 + pending
thankyou
Hi Marco,
/etc/modprobe.d/mt-st should be removed because it duplicates the
functionality of the udev rules but at an higher cost.
I'm not very fond of this idea for several reasons:
* We're talking about 36 files in /etc/modprobe.d/
tags 496305 + pending
thanks
Hi,
When I edit /var/lib/dpkg/status using nvi and then search for a
string (or page down a few times), I get:
Conversion error on line 428
I then can't 428G, but 427G reveals:
nvi with USE_WIDECHAR enabled is just being strict: US-ASCII is a 7-bit
charset, so
tag 518289 + patch
kthxbye
Hi,
I guess this has already been fixed upstream, but for the impatient:
gen_shell_function_matches() is trying to restore a parser state
that has never been saved. My fix is simple and pragmatic as I don't
have any in-depth knowledge regarding whether it's necessary
tags 518397 + pending
thanks
Hi Al,
^A handling is broken; it doesn't generate [[::]] in the end of
resulting pattern, so e.g. after
thanks for your detailed report! I've simplified your patch a little
(there's a widechar-aware STRLEN macro available, and re_compile
null-terminates its
Hi Steve,
The following patch makes this use permissible:
I'm reluctant to apply this patch as-is because the value 20
is hardcoded for $TERM-related buffers all over the place, and
I'd rather double-check these things than simply inflate it
at one single spot. I'll hurry to get things done,
Hi,
I fail to start aptitude and also Midnight Commander (mc) from
inside a screen session. Whenever I start screen -U and in it
mc or aptitude I just get a blank screen, no color, no text,
nothing (but the cursor is repositioned). I cannot even interrupt
mc via Ctrl+C (works with aptitude).
Hi,
Changing the group to utmp is what the screen-cleanup script does indeed, but
only when there was no /var/run/screen before (line 25
of /etc/init.d/screen-cleanup). Maybe it should be inforced generally by
swapping lines 25 and 26?
Reproduced on the freshly stable lenny.
this
Hi Rene,
package: screen
version: 4.00.03 (FAU) 23-Oct-06
which Debian version are you reporting this bug against?
command: screen $pid -X hardcopy $filename
Hm, doesn't fail here:
] j...@apocatequil:~$ screen -dmS test
] j...@apocatequil:~$ screen -ls
] There is a screen on:
]
Hi,
Some things fails to run in a screen session:
$ sg floppy
Cannot execute bash: No such file or directory
$ echo $SHELL
bash
I don't believe this is a bug in screen. Are you sure all your
startup files behave as they are meant to (both for login- and
non-login shells: .profile,
Hi,
sorry it took me so long to get back to you.
I still sometimes get the error WriteMessage: Bad file descriptor
when running screen -r with 4.0.3-11. This is obviously related to
#477739, however the conditions seem somewhat different so I decided
to open a different bug.
Hm. I haven't
tags 515803 + pending
thankyou
Hi,
I've already done so, but the upload is still pending. Freshmeat is not
the real homepage, though, I'd rather list www.gnu.org.
Regards,
Jan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
tags 497349 + pending upstream
thankyou
Hi,
Withing nvi, placing the cursor over a number and pressing the # plus
#, +, or - should increment or decrement that number, but now it erases
everything from the cursor to the end of the line.
yep, you're right - the v_increment command is not
Hi David,
Performing the following steps on the Debian nvi packages 1.79-26 and
1.81.6-3 produces different results.
that's strange - I can reproduce it with both versions here. Note
however that the behaviour is different if the file in question was
not executable when the editor opened it
Hi Raphael,
your report is correct, but if /var/tmp/vi.recover was really a symlink
to some existing directory (like /), mkdir -p won't fail at all - in fact,
it won't even be executed because the [ -d ] test will already succeed.
I'll fix it properly - thanks for catching it.
Regards,
Jan
tags 495806 + unreproducible
thankyou
Hi Troy,
I can't reproduce the problem, no matter which PAM version I have installed
(0.99.7 or 1.0.1). You are referring to the password prompt that screen shows
upon resumption of a screen session that has been locked with the 'lockscreen'
command, right?
Hi,
1.81.6-3 depends on libdb4.2, but the latest libdb in Debian is libdb4.7.
The default libdb-dev depends on libdb4.6 currently.
I build a nvi for libdb4.6, and it works fine.
(I did not test it for libdb4.7.)
I did indeed try a build against libdb4.6, and the results didn't satisfy
me.
Hi,
I've done a bit of backtracking:
* Offending instruction(s):
] [EMAIL PROTECTED]:~$ gdb /usr/bin/audacious core.11650
] GNU gdb 6.8-debian
] (gdb) disass $eip $eip+32
] Dump of assembler code from 0x80a4122 to 0x80a4142:
] 0x080a4122 [EMAIL PROTECTED]:movsd -0x18(%ebp),%xmm0
]
Hi Bernd,
I'm currently working with upstream to re-enable UTF support
for ircii - they have reverted the old UTF patch in 2006 for
performance reasons.
As IMHO it doesn't make sense to upload a new Debian package
that lacks UTF support, I won't change this package in the
near future (read: at
Hi,
If the user accidentally pressed ^a ^\, screen will ask Do you really
want to kill all screens and exit? (y/n). but it will go on and kill
everything without actually waiting for the user to press n.
I cannot reproduce this - screen waits at the prompt and properly accepts
a 'n'o answer.
severity 330782 grave
tags 330782 + help
thankyou
(bumping the severity up to grave because of possible data loss)
Ok, this one has been lying around for far too long. If anyone feels like
diving into ancient sourcecode, I'd highly appreciate that. Here's a
little teaser:
=
Core was
tags 330782 = pending
thankyou
Heh, tagging such a bug 'help' sometimes adds that bit of extra
motivation that helps you find the problem yourself in the end. ;)
A patched (a one-liner in a very innocent-looking part of the code)
version is ready and will be uploaded in the next days.
Regards,
Hi,
In the meantime, I noticed the bug report requesting the upgrade to
6.31. Actually, I think the latest version is 6.31N.
Ah, that link is alive again? It has been dead for some time...
According to the site, it contains a set of patches for bug fixes known
not to cause problems and
Hi,
I checked /var/run/screen and it is owned by user root group root,
so it is not group utmp. Since this used to work, maybe the pre-
install script should enforce the group?
so changing the group to utmp fixed the problem?
I'm at a loss how that directory has ended up with group root on
Hi,
any news on this?
Regards,
Jan
signature.asc
Description: Digital signature
Hi Andreas,
did you check the suid bits on the screen binary? What is
the status of this bugreport?
Regards,
Jan
signature.asc
Description: Digital signature
Hi,
is the interval structure and the bisearch function necessary?
I can't find a code path that calls it. Besides that the patch
looks good and I'll include it in the next upload.
Thanks!
Jan
signature.asc
Description: Digital signature
Hi,
When I start aptitude in screen, the cursor goes to the top left
position and just stays there, aptitude UI is now drawn until I resize
the terminal that holds the screen. After that aptitude works OK.
I can't reproduce this one either (using a standard xterm and a ISO8859
locale). What
Hi,
what's the current public opinion on this? The responses I got in
November 2006[1] indicated that this metapackage is not desired and should
not be re-added to the list - however it's still in widespread use...
] [EMAIL PROTECTED]:~$ for DEP in Provides Depends Recommends Suggests; do \
]
Hi,
[EMAIL PROTECTED]:~$ PS1=$
134$
134 is still there...
(my terminal is in Tranditional-Chinese UTF-8 charset. Does that matter?)
ok, we'll have to dig a bit deeper.
Could you please install strace (if you haven't already) and do the following:
* start a screen session as usual
* do a
Hi,
hmm, that's interesting. Here's what it should look like (or what it looks
like when I just press Return in screen)...
# screen forwards the keypress to the shell...
read(3, \r, 4096) = 1
write(6, \r, 1) = 1
# ... and the shell moves the cursor to
Hi,
and yes, the prompt colour is correct..
any suggestion to fix it?
you keep forgetting to answer *all* my questions. ;)
I'll make a list...
* Is the 134 coloured, too?
* If you do 'echo -e $PS1', does it result in some strange extra characters,
too? (Besides printing \u for your username
Hi,
please respond to [EMAIL PROTECTED] (Sending your answers to
submit@ will result in every message generating a new report.)
[EMAIL PROTECTED]:~$ -something like this
Yes, that's what I suspected it to look like - but this doesn't
answer my questions. Did you try any of my suggestions?
Hi,
1.shell (csh instead of bash, for example)
this does workbut I could'nt change my shell...plz I mean for daily
use, I need bash...
2.terminal emulator (xterm / eterm / one of the *xvt series)
this does'nt help
the 134 is still there
ok, these two suggest that there's
Hi,
(should I reply to the bug reply system? sorry if I reply to the wrong
address)
just respond to [EMAIL PROTECTED], so your mail gets automatically
appended to the bug report log.
here is my $PS1
Ah ok, you are using the coloured prompt. Does the colour work (i.e.
is the prompt inside
tag 477739 + confirmed
thankyou
Hi Aaron and Jason,
I am also experiencing this bug on my dual-cpu (quad-core) Intel Xeon 5140
system with 4gb RAM. However, on my laptop (single-core AMD Athlon64 CPU,
1.8ghz, 1gb RAM) with exactly the same kernel and screen 4.0.3-8, I can't
reproduce it.
I
tags 477739 = patch pending
thankyou
Hi,
could you try this updated package[1] and report back whether it
fixes the race? If it does, I'll add a few more fixes and arrange
for having it uploaded during the next days.
Regards,
Jan
[1]:
Hi,
I'm not the maintainer, so I'm not sure if there is any chance
of changing screen/screen upstream to have a new build dependency.
If there is then that is obviously preferred.
I don't like the idea of introducing additional build dependencies,
and I don't think upstream would be very
reassign 477455 vte
retitle 477455 vte: backspace-autodetect mode uses c_cc[VERASE] even when
ICANON|ECHOE unset
thankyou
Hi,
With some terminals, such as xfce4-terminal (Debian package) and
osso-xterm (not in Debian), screen views the Backspace key as the
nul character (^@), so that it is
Hi,
a number like 134 shows before my bash prompt after I create a new window
in screen...
have you followed the usual procedure to make sure this is screen-related?
(Some commands in your shell rc files might run haywire, probably depending
on $TERM or similar...) - Is it a part of the
Hi Aaron,
As of version 4.0.3-8, resuming a detached screen session (with
screen -r) fails with the cryptic error
WriteMessage: Bad file descriptor
4.0.3-7 has no such trouble, and can even resume sessions started with
4.0.3-8.
can you spot a pattern? (Happens only when several sessions
Hi,
It's fixed. Thanks! (What was it? There is no description.)
thanks for verifying. I wanted to be sure that I'd found the right
place before elaborating what the problem was. The bug could be triggered
by making rxvt execute the following escape sequence:
'\e[1;19r\e[10S'
This reduces the
Hi Ben,
Doesn't the ctime value from fstat(2) give the time the session was
created? That seems like a more useful criterion.
all three timestamps are modified by detach/attach. Writing messages
to the fifo changes mtime and ctime (the latter being quite strange),
receiving changes atime, and
Hi,
all three timestamps are modified by detach/attach. Writing messages
to the fifo changes mtime and ctime (the latter being quite strange),
That is strange. Perhaps it warrants another bug report? This bug
could then depend on that one.
no, that observation wasn't even related to
Hi Josip,
Okay, I would be happy to try and narrow it down some more - just give me
more hints where to look... what would be next - terminfo? locales?
good news: I think I've found it. Could you please verify that this update[1]
fixes the bug?
Thanks!
Jan
[1]:
Hi,
Further investigation shows this is defined behaviour for Unix (and
correctly implemented in Linux).
yes, I suspected that, but couldn't find anything myself - bad google-fu
tonight. Thanks for looking it up.
So it seem that there is currently no useful file-status time field to
order
Hi,
the only timestamp we have is the time of last attachment/detachment (and we
can't
even tell them apart), and I don't think that sorting by that criterion is
incredibly useful... so I'd like to tag this bug 'wontfix' if no-one objects.
Regards,
Jan
signature.asc
Description: Digital
Hi,
I've report it to vim maintainer and I don't know if this is a vim bug
or a screen bug. However vim got an update yesterday and this situation
got even worse. So I report this to screen maintainer as well.
thanks if you can find the conflict part.
It will be great if anyone'd like to
Hi,
The current permissions of /var/run/screen would be useless, because I
have changed it manually to the correct permissions already; otherwise I
can't run screen at all, and I use it every day and I only reboot this
machine for equipment upgrades or kernel upgrades.
The current
Hi,
I cannot reproduce this bug (with and without vbell, using gnome-terminal,
xterm and other terminal emulators) - could you please affirm that the
problem still exists? Otherwise I'm going to close this bug in a few weeks,
given that the report is five years old...
Regards,
Jan
Hi,
When i try to use any of commands in vim (i to insert mod, : to
write :q and so on), I got strange message, but vim is still
running, no crash, only this text:
:*** debug [lib/liblow.c(212)]:
VC: 0
I cannot reproduce this bug with the current versions of
Hi,
The /etc/init.d/screen-cleanup script, provided by package screen,
chmod's /var/run/screen to a mode that will cause the screen command
itself, also provided by the same package, to refuse to start up.
would you please show me the current permissions of both /usr/bin/screen
and
1 - 100 of 214 matches
Mail list logo
