Package: mt-st
Version: 0.9b-1
Severity: serious
Tags: pending
(filing this bug against myself to prevent 0.9b-1 from migrating to
testing, thus saving our testing users from having to play dependency
ping-pong)
Package's changelog mentions a new build-dep on linux-kernel-headers,
introduced was
retitle 426808 tar: using -W circumvents sanity checks and provokes data loss
thankyou
Hi,
it gets even worse...
] [EMAIL PROTECTED]:/tmp>touch X
] [EMAIL PROTECTED]:/tmp>tar czf XT X
] [EMAIL PROTECTED]:/tmp>file XT
] XT: gzip compressed data, from Unix, last modified: Sat Jul 7 18:36:01 2007
package autofs5
tags 433546 + pending
thankyou
Hi Martin,
> Version: 5.0.2-1
> Severity: serious
> Justification: Fails to build from source
> Tags: experimental
I know, I've already studied the experimental buildd logs and
fixed my package. I'm currently waiting for my sponsor to
upload my fix.
package autofs5
merge 433551 433546
tags 433546 + pending
retitle 433546 autofs5: arch-independent FTBFS
thankyou
Hi Frank,
> Package: autofs5
> Version: 5.0.2-1
> Severity: serious
I know, I know. ;) It is already fixed and waiting to be uploaded.
I'm reading the buildd logs regularly, especial
tags 445360 + unreproducible
thankyou
Hi Josip,
(gdb) p TermWin.nrow
$37 = 24
(gdb) p (text_t *[24])*(screen.text + TermWin.saveLines)
$38 = {
0x543a10 "i:Exit -:PrevPg :NextPg v:View Attachm. d:Del r:Reply
j:Next ?:Help ",
0x543d40 "X-Spam-Level:", ' ' ,
0x544070 "Delivery-date: S
Hi,
> How do I get gdb to work with this? I've tried running it until that point,
> and then Ctrl+Z it in gdb to be able to type commands, but then:
that's exactly the way to do it (I use CTRL+C, but that shouldn't matter).
The problem is that rxvt is built with too little debugging info, regardl
Ah,
forgot one thing, to avoid a misunderstanding, because you quoted
my gdb output: those NULL pointers are in _your_ session. I
extracted that from your second core file.
The contents of the display have already been partially replaced
at the time of the crash... the lines above the five 0x0s ar
Hi,
> Ah, yes, true. Here you go:
ok, the results are really strange. A comparison between the lists of pointers
before and after the crash...
] (BEFORE)
> $1 = {
> 0x54dfa0 "i:Exit -:PrevPg :NextPg v:View Attachm. d:Del r:Reply
> j:Next ?:Help ",
> 0x541d60 "Delivery-date: Sun, 22 Ju
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
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 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 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,
> 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
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 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
-
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,
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
-- Jan Christoph Nordholz
--- system-tools-backends-2.6.0.orig/Users/Users.pm 2008-03-
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 m
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 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
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
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
tags 394778 + pending
thankyou
Hi Paul,
thanks for your report - fix is included, I will ask my sponsor to upload
soon.
Regards,
Jan
signature.asc
Description: Digital signature
Hi Steven!
> I'm working away at a BSP just now, and came across this bug. Do you
> need a sponsored upload? Can I just upload an NMU with the patch in the
> BTS? Whatever works for you.
Sure, just go ahead and do a NMU. I've already got some more changes in
my local build area which I haven't
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,
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/
30 matches
Mail list logo