Hi Ben, hi Yannick,
(commenting on both #437024 and #439628)
>> Does this patch could fix the fact than when I run screen with as
>> argument a non-existing program, I have
>>
>>> Cannot exec 'sdfsdfsdf': Aucun fichier ou répertoire de ce type
>> (LANG is fr_FR.UTF-8) [should be réper
Hi Dan,
how would you improve the documentation? There's nothing more
to the split command... as the manpage states, it creates a
blank region, 'C-a ' jumps between regions, and then you're
free to do what you want with it (and eventually dispose of it
with 'remove' or 'only'). What do you have in
Hi Laurent,
can you still reproduce this? I've just done some tests (using
'-efont-fixed-medium-r-normal--16-160-75-75-c-160-iso10646-1'
inside uxterm+screen) and my screen gets cleaned properly.
Regards,
Jan
signature.asc
Description: Digital signature
severity 354709 minor
thankyou
Hi Jon,
the UTF is invalid. "Regular" shells and ones inside screen behave
differently, presumably caused by that extra layer of indirection:
e.g. "echo -e '\xe6\xac__'" displays one underline without, and two
within screen. ( starts a 3-byte UTF8 sequence. Regular
tags 443768 + pending
thankyou
Hi Paul,
> Instead of /tmp/.screen being created as a symlink to /var/run/screen,
> a symlink to /var/run/screen was created in /tmp/.screen/, causing me
> a moment of panic when I couldn't find my old screen sessions.
>
> This probably was caused by me started a n
tags 433813 + pending
thankyou
Hi,
unrelated to #443768, but indeed a script error (an if block opened
too late). Upload pending. Thanks for noticing!
Regards,
Jan
signature.asc
Description: Digital signature
Hi,
I don't experience this behaviour and don't remember that I
ever did. (Besides, I follow the tcpdump upstream mailing list
quite closely, and I think I would have noticed when such a bug
had been fixed... ;) )
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 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 sa
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
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,
> 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 can
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,
Jan
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
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 wi
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 /etc/auto.mis
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
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
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 termina
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 permis
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 o
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 sizeof
th), but don't
+ bump Standards version.
+
+ -- Jan Christoph Nordholz 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-shi
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 /var/run
Hi Andreas,
> When connecting as another user in mode "multiuser on", then the primary
> created session says "attach attempt with bad pid".
is your /usr/bin/screen setuid root? This is mandatory if you want to use
the multiuser feature. Have a look at /usr/share/doc/screen/README.Debian.
Note t
Hi Trent,
> Lately I have noticed that if this idle timer engages while the
> bottom-right corner character is bold and underlined, the password
> prompts are also bold and underlined. This is irritating. I would
> like screen to issue an sgr0 before switching to the password prompt,
> so the pr
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
signature.a
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
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 sign
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
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 p
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
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]: http://www-pool.math.tu-ber
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
> or
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
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
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.
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]: http://www-pool.math.tu-berlin.de/~hesso/deb/screen_4.0.3-
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 ver
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? Cha
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 ther
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
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 use
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
*
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
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 \
] > e
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,
> 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,
> 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 an
Hi Lucas,
> I can now reproduce it, sorry. maybe its a random failure?
here's a diff of your buildlog against one of mine... rxvt is reconfigured
and built several times in a row during 'debian/rules build'... this is
the last run:
] [...] (your log -- my log)
] creating config.h
Hi Raphael,
> What's the status of this ITA?
> Note that, just like Lucas, I'm not interested in inform myself, but just
> checking packages that should probably be removed.
>
> It would be nice if you could provide some status information or even closing
> this report by uploading a new packag
Hi Josip,
> Ha, found it - it's just one setting:
>
> XTerm*termName: xterm-debian
>
> The first step to reproduce can be changed to:
>
> xrdb -remove && xrdb -merge rxvt-bug.Xresources && rxvt
even with that resource setting I cannot reproduce it. And that's why
I had tagged the bug 'unreprod
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 answ
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 generate
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 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 le
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
] 0x0
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 (
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 w
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
m
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
owner 454258 !
retitle 454258 ITA: inform -- A compiler for adventure games
thankyou
Hi Lucas,
thanks for bringing this to my attention! When I had taken inform-mode,
I had also looked at inform, but there were no removal bugs then, so
I assumed the package was still looked after.
I use inform f
tags 452643 + pending
thankyou
Hi,
> Found some typos in '/usr/share/man/man1/mrxvt.1.gz', see attached '.diff'.
thanks, included!
Regards,
Jan
signature.asc
Description: Digital signature
Hi,
> 'Menu>Tabs>Save config' crashes like so:
>
> % mrxvt -showmenu ; echo $?
> Segmentation fault
> 139
hmm, I can't reproduce that. Could you run mrxvt in strace or attach strace
to the process before the crash?
Regards,
Jan
signature.asc
Description: Digital signature
Package: gnutls-bin
Version: 2.1.6-1
Tags: experimental
Hi,
there's a problem with gnutls-{cli,serv} in the new gnutls-bin:
] [EMAIL PROTECTED]:~$ ldd /usr/bin/gnutls-cli
] linux-gate.so.1 => (0xb7f6f000)
]>>> libgnutls.so.25 => /usr/lib/libgnutls.so.25 (0xb7ee4000)
]>>> libgn
Package: weechat
Severity: wishlist
Hi,
as OFTC has recently added support for authentication via SSL certificates,
it would be great if weechat would gain that ability, too.
I've already created a patch that achieves this (which proved to be a bit
tricky because gnutls won't select self-signed
severity 453720 minor
tags 453720 + pending
thankyou
Hi Adam,
I fully agree with you - this setting doesn't need a compile-time
limit. I'm going to remove it.
Thanks!
Jan
signature.asc
Description: Digital signature
Hi,
just sorting through old bug reports... have you ever managed
to reproduce this bug (with old or new versions of the mentioned
software packages)? If so, could you give me a description how?
Regards,
Jan
signature.asc
Description: Digital signature
Hi James,
(sorting through screen's bug list because I intend to adopt the package
if Adam agrees)
does this still apply? My build reads
] configure: checking select...
] configure: checking fifos...
] - your fifos are usable
] configure: checking for broken fifo implementation...
] - your imple
package screen
merge 387156 413674
tags 387156 = pending
thankyou
Hi,
I've gathered that the corresponding cowdancer bug (#413912) has been fixed,
so this issue doesn't exist anymore. I'll include a post-configure assertion
into the next screen upload so that future versions will FTBFS instead of
tags 374471 + pending
thankyou
Hi Justin,
I'm taking over the package and preparing a new upload. I have removed
the /var/run/screens block because I couldn't find any other references
to that directory, and I have moved the calls to remove-shell to
prerm:remove, prerm:deconfigure and postrm:disa
package screen
tags 385895 + pending
tags 397088 + pending
tags 390506 + pending
thankyou
Hi,
initscripts is prio: required, but not Essential, so I'm reluctant to
remove those lines... but I agree that /var/run/screen should be created
automatically. I've checked in a fix that also removes the e
retitle 348657 screen refuses to spawn login shells
tags 348657 = moreinfo unreproducible
thankyou
Hi Thomas,
I also suspect there's something wrong with your shell...
] [EMAIL PROTECTED]:~$ cat .screenrc
] shell -/bin/bash
] [EMAIL PROTECTED]:~$ screen
] [>>>]
] [EMAIL PROTECTED]:~$ shopt | gr
Hi,
(taking over maintainership from Adam)
is there any news regarding this bug? Is it still reproducible? If so,
have you been able to discern a pattern on which hosts it fails? Or
have you upgraded to Etch in the meantime?
Regards,
Jan
signature.asc
Description: Digital signature
Hi Branden,
did your line "on my PowerPC" imply that this is a ppc-only bug?
At least on i386 I can't get screen to segfault (although the screen
refresh is admittedly a bit suboptimal when paging through the glyph
table).
It's going to take a few more days until I have my ppc up and running -
do
severity 291253 minor
tags 291253 + moreinfo unreproducible
thankyou
Hi,
I also cannot reproduce the bug. With the proper utf8 locale set, the UTF8 demo
displays fine in a regular uxterm and inside screen. I don't even need -U.
I'll keep this bug at minor severity for a few more weeks, in case a
Hi Josip,
> Certain niche actions in mutt have been reproducibly crashing my rxvt
> since I've upgraded to etch.
>
> Here's a test case:
I can't reproduce that bug. Could you get me a core dump? What locale do
you use?
Regards,
Jan
signature.asc
Description: Digital signature
Hi,
> It doesn't produce a core dump.
>
> % ulimit -c
> unlimited
> % rxvt
> [run the actions in the invoked rxvt until it crashes]
> zsh: segmentation fault rxvt
hm, strange, it should... what does gdb say? Does something like
this work?
] [EMAIL PROTECTED]:~$ gdb
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
/build/buildd-glib2.0_2.25.12-1-i386-5iccNM/glib2.0-2.25.12/
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? Co
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,
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 to
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/ inst
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 expr
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 (
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, .b
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 have
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 anyw
101 - 200 of 214 matches
Mail list logo
