Bug#840700: g-brief2: 'Command \c@blockzahl already defined' on multiple inclusions

2016-10-13 Thread Julius Seemayer
Package: texlive-latex-extra
Version: 2016.20161008-1
Severity: minor
Tags: patch

Hi,


g-brief2 currently does not support multiple inclusions. This would be helpful
for bulk letters and is trivial to fix.

Reproducing the issue:

> $ cat simple.tex 
> \documentclass[ngerman]{g-brief2}
> \Gruss {}{1cm} % this can't be left out due to a potential another bug
> \begin{document}
> 
> \begin{g-brief}
> page one
> \end{g-brief}
> 
> %\newpage
> %\begin{g-brief}
> %page two
> %\end{g-brief}
> 
> \end{document}
> $ pdflatex simple.tex; echo $?
> ...
> 0
> $ sed -i 's/^%//' simple.tex
> $ cat simple.tex 
> \documentclass[ngerman]{g-brief2}
> \Gruss {}{1cm} % this can't be left out due to a potential another bug
> \begin{document}
> 
> \begin{g-brief}
> page one
> \end{g-brief}
> 
> \newpage
> \begin{g-brief}
> page two
> \end{g-brief}
> 
> \end{document}
> $ pdflatex simple.tex; echo $?
> ...
> 
> ! LaTeX Error: Command \c@blockzahl already defined.
>Or name \end... illegal, see p.192 of the manual.
> 
> See the LaTeX manual or LaTeX Companion for explanation.
> Type  H   for immediate help.
>  ...  
>   
> l.14 \end{document}
>
> ? ^\Quit
> 131
> $ 

A  trivial  patch  ensures  that the counter is not defined multiple times and
reset if needed:

> --- /usr/share/texlive/texmf-dist/tex/latex/g-brief/g-brief2.cls  
> 2016-10-13 23:10:26.630778157 +0200
> +++ /usr/share/texlive/texmf-dist/tex/latex/g-brief/g-brief2.cls  
> 2016-10-13 23:10:31.726871803 +0200
> @@ -333,7 +333,7 @@
>  \unitlength1mm
>  \begin{picture}(0,0)
>\put(-9,0){\parbox{180mm}{
> -\tiny \newcounter{blockzahl} \def\@blockbreite{170mm}
> +\tiny 
> \ifdef{\theblockzahl}{\setcounter{blockzahl}{0}}{\newcounter{blockzahl}} 
> \def\@blockbreite{170mm}
>  \iftrennlinien \rule{180mm}{0.5pt} \fi
>  \ifthenelse{
>\equal{\namezeilea}{\empty} \and \equal{\namezeileb}{\empty} \and

Please include that patch. Thanks!


All the best,

Julius



Bug#791366: lvm2: lvs --unbuffered segfaults when using --select regex

2015-07-04 Thread Julius Seemayer
--[ Peter Rajnoha prajn...@redhat.com 2015-07-04 10:58:44 +0200 ]
 I think this is fixed already with this upstream patch (appeared in lvm2
 v2.02.115):
 
 https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=f94f8463b0d3dddaa0e429123aba673d106f783e
 

This  looks  very  much like the behaviour I see. I didn't test the patch yet,
though.

--[ Julius Seemayer deb...@yeeer.net 2015-07-04 11:16:14 +0200 ]
 [...]
 - output is attached to this message.

Of  course I failed to attach the log, but it seems rather pointless since the
bug got confirmed and patched elsewhere.

Thanks for the quick reply to both of you!


Cheers,

Julius


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#791366: lvm2: lvs --unbuffered segfaults when using --select regex

2015-07-04 Thread Julius Seemayer
--[ Alasdair G Kergon a...@redhat.com 2015-07-04 10:35:16 +0200 ]
 On Fri, Jul 03, 2015 at 11:50:39PM +0200, Julius Seemayer wrote:
  Please tell me if/how I can help to further debug this issue.
  
 1) People need to see the complete debug output from the failing command with
 - added.  That is what enables people to reproduce issues.

- output is attached to this message. Note that I moved the debugging over
to another host to avoid disclosure of internal paths etc.. The issue is still
reproducible in the very same manner.

 2) There have been a lot of changes to the reporting code since that release,
 so the first thing is to try a recent release to see if the bug is already
 fixed upstream.

While  I  generally  agree  to  your  hint,  lvm2 in particular seems to be as
version  2.02.111-2.2  in  all  of  stable,  testing  and unstable. Since both
libdevmapper*  and  the  binary lvm2 administration tools should have the same
version in testing/unstable, I decided not to upgrade and test again.


Cheers,

Julius


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#791366: lvm2: lvs --unbuffered segfaults when using --select regex

2015-07-03 Thread Julius Seemayer
Package: lvm2
Version: 2.02.111-2.2
Severity: normal

Hi,


lvs --unbuffered in Jessie seems to be broken:

sh# ulimit -c $((1024*1024))
sh# lvs vm --select 'lv_name =~ .*img' --unbuffered || echo $?
  LV   VG   Attr   LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync 
Convert
  test.img vm   -wi-a- 8.00g

  deb-installer.img vm   -wi-ao 8.00g   
 
Segmentation fault (core dumped)
139
sh# gdb -q lvs core
Reading symbols from lvs...(no debugging symbols found)...done.

warning: core file may not match specified executable file.
[New LWP 23047]
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
Core was generated by `lvs vm --select lv_name =~ .*img --unbuffered'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7ff74c9a9ab8 in dm_bit_and () from 
/lib/x86_64-linux-gnu/libdevmapper.so.1.02.1
(gdb) bt
#0  0x7ff74c9a9ab8 in dm_bit_and () from 
/lib/x86_64-linux-gnu/libdevmapper.so.1.02.1
#1  0x7ff74c9cf18c in ?? () from 
/lib/x86_64-linux-gnu/libdevmapper.so.1.02.1
#2  0x7ff74c9cf3a2 in ?? () from 
/lib/x86_64-linux-gnu/libdevmapper.so.1.02.1
#3  0x7ff74c9d00a2 in dm_regex_match () from 
/lib/x86_64-linux-gnu/libdevmapper.so.1.02.1
#4  0x7ff74c9c5111 in ?? () from 
/lib/x86_64-linux-gnu/libdevmapper.so.1.02.1
#5  0x7ff74c9c4ed7 in ?? () from 
/lib/x86_64-linux-gnu/libdevmapper.so.1.02.1
#6  0x7ff74c9ca2f4 in dm_report_object () from 
/lib/x86_64-linux-gnu/libdevmapper.so.1.02.1
#7  0x7ff74d4e0ee9 in report_object ()
#8  0x7ff74d467e82 in ?? ()
#9  0x7ff74d469a95 in process_each_lv_in_vg ()
#10 0x7ff74d46b494 in process_each_lv ()
#11 0x7ff74d468507 in ?? ()
#12 0x7ff74d45f258 in lvm_run_command ()
#13 0x7ff74d45f8ee in lvm2_main ()
#14 0x7ff74c3d9b45 in __libc_start_main (main=0x7ff74d44a6f0 main, 
argc=5, argv=0x7ffe2708, init=optimized out, fini=optimized out, 
rtld_fini=optimized out, 
stack_end=0x7ffe27eeedf8) at libc-start.c:287
#15 0x7ff74d44a71e in _start ()
(gdb) q
sh# 

I'm  pretty  sure  that  the  issue is related to the regex expansion, since a
fixed string comparision ('=') works fine:

sh# lvs vm --select 'lv_name = test.img' --unbuffered || echo $?
  LV   VG   Attr   LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync 
Convert
  test.img vm   -wi-a- 8.00g

sh# 

Also,  the  output  does  always  consist of two lines plus header, before the
segfault occurs. I can confirm this on another host.

It  is  important to have at least four LVs inside a VG, this will trigger the
segfault.  Having  exactly  three  LVs  does  not segfault, but causes _wrong_
output (the last entry does not get displayed).

Please tell me if/how I can help to further debug this issue.


Cheers,

Julius



-- System Information:
Debian Release: 8.1
Architecture: amd64 (x86_64)

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#736214: reportbug: SMTP transmission issues can cause complete loss of bug report

2014-05-01 Thread Julius Seemayer
tag 736214 confirmed
severity 736214 important
thanks

Hi,


I can confirm this bug,  at least parts of it.  If something goes wrong on the
'send via mail' part,  it is not possible to recover the bug report.   This is
very  bad,   since  a  bug  submitter  is forced to rewrite his/her entire bug
report.  At this point many to-be bug reporters will throw the towel and leave
the bug unreported, I think.

And no,  'fix your mail setup' is not an option.  If the user notices that the
reportbug  mail  gets lost,  (s)he needs a backup to resend after fixing their
MTA/network/whatever.  Right now there is no such backup.

This  should be fixed as soon as possible,  at least keep the /tmp/reportbug-*
file containing the report and point the user to them.


Cheers,

Julius



P.S.: re-tagging as important (not grave), because it's very annoying.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#745963: rsnapshot: linux_lvm_cmd_lvremove is not silenced (lvcreate is)

2014-04-26 Thread Julius Seemayer
Package: rsnapshot
Version: 1.3.1-3
Severity: normal
Tags: patch

Hi,


rsnapshot   seems   to   be   wrongly   patched   at  one  point,   hence  the
linux_lvm_cmd_umount system() call is silenced,  but linux_lvm_cmd_lvremove is
not.   Since  only the latter is noisy by default (fix that,  lvm guys!),  the
wrong one is muted.

This applies for stable and sid, at least.

Patch:

--- /usr/bin/rsnapshot  2011-07-09 16:39:45.0 +0200
+++ rsnapshot   2014-04-26 20:34:12.0 +0200
@@ -3725,38 +3725,38 @@
 }
 }
 
 @cmd_stack = ();
 push(@cmd_stack, $config_vars{'linux_lvm_cmd_umount'});
 
 push(@cmd_stack, $config_vars{'linux_lvm_mountpath'});
 
 print_cmd(@cmd_stack);
 if (0 == $test) {
-# silence gratuitous lvremove output
-#$result = system(@cmd_stack);
-$result = system(join  , @cmd_stack, /dev/null);
+$result = system(@cmd_stack);
 
 if ($result != 0) {
 bail(Unmount LVM snapshot failed: $result);
 }
 }
 
 @cmd_stack = ();
 push(@cmd_stack, $config_vars{'linux_lvm_cmd_lvremove'});
 
 push(@cmd_stack, '--force');
 push(@cmd_stack, $linux_lvm_snapshotname);
 
 print_cmd(@cmd_stack);
 if (0 == $test) {
-$result = system(@cmd_stack);
+# silence gratuitous lvremove output
+#$result = system(@cmd_stack);
+$result = system(join  , @cmd_stack, /dev/null);
 
 if ($result != 0) {
 bail(Removal of LVM snapshot failed: $result);
 }
 }
 }
 }
 
 # accepts the name of the argument to split, and its value
 # the name is used for spitting out error messages

(note the ... lvremove output comment,  which is obviously placed inside the
wrong if(0==$test){} scope)

Please  fix that,  right now I'd get cron mails for every single rsnapshot run
(without my patch applied).


Cheers,

Julius


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#740271: d-i fails to purge LVM despite preseeding

2014-04-24 Thread Julius Seemayer
Hi,


I  recently  stumbled  across  the very same bug while setting up an automated
installation environment.   So far my solution or rather workaround looks like
this:

 # this will DESTROY any VGs and PVs found
 d-i partman/early_command string sh -c 'set -- $(vgs --rows --noheadings | 
 head -n 1); for vg in $@; do vgremove -f $vg; done; set -- $(pvs --rows 
 --noheadings | head -n 1); for pv in $@; do pvremove -f $pv; done'

It might not be perfect but will destroy/wipe any recognized volume groups and
physical  volumes.   In contrast to simply 'dd if=/dev/zero'ing the disc it is
much  faster,  but will only solve the LVM specific problem.   E.g.   md-RAIDs
might  still exist.   I'm not sure if d-i will also choke itself in this case,
but it's not topic of this bug.

The expanded and pretty formatted code looks like this [1]:

 d-i partman/early_command string sh -c '
   set -- $(vgs --rows --noheadings | head -n 1);
   for vg in $@; do
   vgremove -f $vg;
   done;
   
   set -- $(pvs --rows --noheadings | head -n 1);
   for pv in $@; do
   pvremove -f $pv;
   done
 '

It  will  obviously  choke on VGs or PVs that contain a whitespace [2],  but I
think  such  a identifier would be invalid as well.   As I stated above,  it's
just a workaround; a proper fix should be done inside d-i.


Cheers,

Julius



[1] d-i  seems  not to like escaped newlines (\CR) in the preseed.cfg in any
cases, hence the first one is one-line
[2] set -- $(echo 'a b' c)   would   create   three  arguments,  thus  three
invocations of the in-loop code


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#739246: btrfs-tools: command line arguments get eaten

2014-02-16 Thread Julius Seemayer
Package: btrfs-tools
Version: 0.19+20120328-7.1
Severity: important

The  btrfsck  from  the Wheezy btrfs-tools package doesn't handle command line
arguments properly, e.g. 

# btrfsck -f /dev/vdb1 || echo fail
btrfsck: invalid option -- 'f'
usage: btrfsck dev
Btrfs Btrfs v0.19
fail
# btrfsck -a -f /dev/vdb1 || echo fail
Btrfs Btrfs v0.19
# btrfsck -a dummy /dev/vdb1 || echo fail
Btrfs Btrfs v0.19
# 

 The  argument  after  -a gets obviously eaten.  -f should cause an error, as
'dummy' should. (The combination -a -f is used in the /etc/init.d/checkroot.sh
and /etc/init.d/checkfs.sh scripts.)

Note:  The  Jessie  and  later  packages moved the code from btrfsck.c code to
btrfs.c, along  with a very different argument parsing.  I haven't checked but
those versions are probably not affected.


Cheers,

Julius


-- System Information:
Debian Release: 7.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)

2014-02-16 Thread Julius Seemayer
tag 686895 + patch
thanks

Hi,


I  ran  into the very same bug.  It seems to be a more conceptual problem than
btrfs-related, but for making btrfsck work, I added this patch: 

--- checkroot.sh2014-02-16 23:34:17.349214647 +
+++ /etc/init.d/checkroot.sh2014-02-16 23:42:03.19371 +
@@ -187,6 +187,12 @@
if [ -f /forcefsck ] || grep -s -w -i forcefsck /proc/cmdline
then
force=-f
+
+   # btrfsck doesn't know -f
+   mount | while read dev on path type fs fnord; do
+   [ x/ = x$path -a xbtrfs = x$fs ] \
+break
+   done  force=
else
force=
fi

  It  checks  if  /  is  a btrfs file system and then removes the -f from the
fsck(8)  command  line.  I don't know if it's sensible to add something like a
blacklist for file systems whose fsck doesn't know -f at this place. 


Cheers,

Julius


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#703211: btrfs-tools: btrfsck doesn't do anything by default and doesn't document command line options

2014-02-16 Thread Julius Seemayer
tag 703211 + confirmed
thanks

Hi,


I  can confirm this bug.  The man page is nearly unusable and doesn't document
any  parameters,  even  though the btrfsck binary accepts them.  (Although the
argument handling is broken in Wheezy, see #739246.)


Cheers,

Julius


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#736821: fookebox: no input validation for search function (XSS)

2014-01-26 Thread Julius Seemayer
Package: fookebox
Version: 0.6.1-1
Severity: normal
Tags: security

Hi,


the  search  function  of  fookebox MPD web interface suffers from classic XSS
vulnerability;  a  search  string  like  'scriptalert(/xss/)/script'  will
launch  an  alert  box.   It's  using  AJAX  and POST, so I'm not sure if it's
exploitable easily from remote hosts.


Cheers,

Julius



-- System Information:
Debian Release: 7.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#733262: apt-mirror broken for armhf debian.org/.../main/binary-arm/Packages.gz: No such file

2013-12-27 Thread Julius Seemayer
Package: apt-mirror
Version: 0.4.8-5
Severity: important
Tags: patch

Hi,


mirroring armhf architecture doesn't work:

$ apt-mirror mirror.list
Downloading 13 index files using 13 threads...
Begin time: Fri Dec 27 22:16:42 2013
[13]... [12]... [11]... [10]... [9]... [8]... [7]... [6]... [5]... [4]... 
[3]... [2]... [1]... [0]...
End time: Fri Dec 27 22:16:42 2013

Proceed indexes: [Psh: 1: cannot open 
ftp.de.debian.org/debian//dists/wheezy/main/binary-arm/Packages.gz: No such file
$ 

Some  debugging  printf()s  show  that the deb-* parser doesn't work properly,
'armhf' gets matched as 'arm'. Dirty, but working patch:

--- apt-mirror  2013-12-27 22:18:27.312722266 +0100
+++ /usr/bin/apt-mirror 2013-12-27 22:18:52.016721234 +0100
@@ -256 +256 @@
-if($config_line =~ 
/deb-(alpha|amd64|armel|arm|armhf|hppa|hurd-i386|i386|ia64|kfreebsd-i386|kfreebsd-amd64|lpia|m68k|mipsel|mips|powerpc|s390|s390x|sh|sparc)/)
 {
+if($config_line =~ 
/deb-(alpha|amd64|armel|armhf|arm|hppa|hurd-i386|i386|ia64|kfreebsd-i386|kfreebsd-amd64|lpia|m68k|mipsel|mips|powerpc|s390|s390x|sh|sparc)/)
 {

Probably one should tighten the regex with \ or something like this.

Cheers,

Julius



-- System Information:
Debian Release: 7.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#696981: munin: Cron job warn about not a reference at /usr/share/perl5/Munin/Master/Utils.pm line 908

2013-12-09 Thread Julius Seemayer
Hi,


I'm currently running into the same issue and did some debugging with the help
of the #munin guys.

The  conditions  to trigger this bug seem to be: munin never ran successfully.
munin-node  is not installed, thus no munin can't pull the default 'localhost'
client,  so  /var/lib/munin/*storable  doesn't  get  created, which causes the
actual error message.

A workaround could be:

* install munin (or already have a 'broken' munin installation)
* install munin-node
* wait for '*/5 * * * *' cronjob or run munin-cron manually (as user munin)
* purge munin-node (probably followed by autoremove --purge)
* find  a  way  to  get rid of localhost.localdomain entries and add your real
  hosts

I'm not sure if that'll work reliable.  Also, I'm not sure if this is actually
the core bug.


Cheers,

Julius


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#727634: udftools: [mkudffs] segfaults while creating file system on non-zeroed storage

2013-10-24 Thread Julius Seemayer
Package: udftools
Version: 1.0.0b3-14.2
Severity: normal

mkudffs is broken for specially crafted files:

$ s=$(mktemp)
$ truncate -s 3TiB $s
$ dd bs=512 count=64 /dev/zero | tr '\0' '\377' $s
64+0 records in
64+0 records out
32768 bytes (33 kB) copied, 0.000170991 s, 192 MB/s
$ mkudffs --media-type=hd --blocksize=512 $s
Segmentation fault (core dumped)
$ 
 (build debugging package)
$ gdb debian/udftools/usr/bin/mkudffs ~/core 
Reading symbols from 
/tmp/tmp.zAW1MYasi5/udftools-1.0.0b3/debian/udftools/usr/bin/mkudffs...done.
[New LWP 6225]

warning: Can't read pathname for load map: Input/output error.
Core was generated by 
`/tmp/tmp.zAW1MYasi5/udftools-1.0.0b3/debian/udftools/usr/bin/mkudffs 
--media-ty'.
Program terminated with signal 11, Segmentation fault.
#0  0x0040648f in next_extent_size (start_ext=0x0, type=USPACE, 
blocks=16, offset=1) at extent.c:53
53  if (start_ext-start % offset)
(gdb) p start_ext 
$1 = (struct udf_extent *) 0x0
(gdb) p start_ext-start 
Cannot access memory at address 0x4
(gdb) i f
Stack level 0, frame at 0x7fff34bc16a0:
 rip = 0x40648f in next_extent_size (extent.c:53); saved rip 0x402580
 called by frame at 0x7fff34bc1730
 source language c.
 Arglist at 0x7fff34bc1690, args: start_ext=0x0, type=USPACE, blocks=16, 
offset=1
 Locals at 0x7fff34bc1690, Previous frame's sp is 0x7fff34bc16a0
 Saved registers:
  rbp at 0x7fff34bc1690, rip at 0x7fff34bc1698
(gdb) bt
#0  0x0040648f in next_extent_size (start_ext=0x0, type=USPACE, 
blocks=16, offset=1) at extent.c:53
#1  0x00402580 in split_space (disc=0x7fff34bc1850) at mkudffs.c:209
#2  0x0040140b in main (argc=4, argv=0x7fff34bc1a98) at main.c:173
(gdb) 

Note:  The dd | tr $s line truncates the file to ~33kB. There seems to be a
relation to:

$ dd bs=512 count=64 /dev/zero $s
64+0 records in
64+0 records out
32768 bytes (33 kB) copied, 0.000216984 s, 151 MB/s
$ /tmp/tmp.zAW1MYasi5/udftools-1.0.0b3/debian/udftools/usr/bin/mkudffs 
--media-type=hd --blocksize=512 $s
Segmentation fault (core dumped)
$ dd bs=512 count=63 /dev/zero $s
63+0 records in
63+0 records out
32256 bytes (32 kB) copied, 0.000215543 s, 150 MB/s
$ /tmp/tmp.zAW1MYasi5/udftools-1.0.0b3/debian/udftools/usr/bin/mkudffs 
--media-type=hd --blocksize=512 $s
trying to change type of multiple extents
$ dd bs=512 count=65 /dev/zero $s
65+0 records in
65+0 records out
33280 bytes (33 kB) copied, 0.000224204 s, 148 MB/s
$ /tmp/tmp.zAW1MYasi5/udftools-1.0.0b3/debian/udftools/usr/bin/mkudffs 
--media-type=hd --blocksize=512 $s
trying to change type of multiple extents
$ 

So it's probably only broken for files with multiples of $blocksize size.

I was just playing around and didn't actually want to break something...


Cheers,

Julius



-- System Information:
Debian Release: 7.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages udftools depends on:
ii  libc6 2.13-38
ii  libreadline6  6.2+dfsg-0.1

Versions of packages udftools recommends:
ii  udev  175-7.2

Versions of packages udftools suggests:
pn  dvd+rw-tools  none
pn  pmountnone

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#727636: udftools: Makefiles broken, cannot compile without -O2

2013-10-24 Thread Julius Seemayer
Package: udftools
Version: 1.0.0b3-14.2
Severity: normal
Tags: upstream

The package won't build for debugging purposes without -O2, even if you use

$ export DEB_BUILD_OPTIONS=nostrip noopt
$ debian/rules ... #or
$ debian/rules ... CC='gcc -O0 -g'

-- the (upstream) makefiles have -O2 hard coded inside. A dirty fix could be

$ find -name Makefile -exec sed -i s/-O2//g '{}' \;

but I'm not sure what it's going to break.


Cheers,

Julius



-- System Information:
Debian Release: 7.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages udftools depends on:
ii  libc6 2.13-38
ii  libreadline6  6.2+dfsg-0.1

Versions of packages udftools recommends:
ii  udev  175-7.2

Versions of packages udftools suggests:
pn  dvd+rw-tools  none
pn  pmountnone

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#726353: rkhunter: must be present on the system messages for all /{s,}bin tools

2013-10-14 Thread Julius Seemayer
Package: rkhunter
Version: 1.4.0-1
Severity: important

rkhunter on a Wheezy box:

# apt-cache policy rkhunter
rkhunter:
  Installed: 1.4.0-1
  Candidate: 1.4.0-1
  Version table:
 *** 1.4.0-1 0
500 http://ftp.de.debian.org/debian/ wheezy/main i386 Packages
100 /var/lib/dpkg/status
# rkhunter -c || echo $?
The command 'cat' must be present on the system in order to run rkhunter.
The command 'chmod' must be present on the system in order to run rkhunter.
The command 'chown' must be present on the system in order to run rkhunter.
The command 'cp' must be present on the system in order to run rkhunter.
The command 'date' must be present on the system in order to run rkhunter.
The command 'egrep' must be present on the system in order to run rkhunter.
The command 'ls' must be present on the system in order to run rkhunter.
The command 'mv' must be present on the system in order to run rkhunter.
The command 'sed' must be present on the system in order to run rkhunter.
The command 'uname' must be present on the system in order to run rkhunter.
1
# 

I didn't change /e/d/rkhunter nor /e/rkhunter.conf, but the very same conf is
running on multiple boxes without problems. Debug log is attached below [1].

As far I can see, the second call on check_required_commands() doesn't include
/{s,}bin, so probably $BINPATHS is set wrong at that time. Manual setting with
--binpath /bin doesn't change the output on stdout/err or in the debug log.


Cheers,

Julius



-- System Information:
Debian Release: 7.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i686

Shell: /bin/sh linked to /bin/dash

Versions of packages rkhunter depends on:
ii  binutils   2.22-8
ii  debconf [debconf-2.0]  1.5.49
ii  file   5.11-2
ii  net-tools  1.60-24.2
ii  perl   5.14.2-21+deb7u1
ii  ucf3.0025+nmu3

Versions of packages rkhunter recommends:
ii  curl7.26.0-1+wheezy4
ii  iproute 20120521-3+b3
ii  lsof4.86+dfsg-1
ii  postfix [mail-transport-agent]  2.9.6-2
ii  unhide  20110113-4
ii  wget1.13.4-3

Versions of packages rkhunter suggests:
ii  bsd-mailx [mailx] 8.1.2-0.2006cvs-1
ii  heirloom-mailx [mailx]12.5-2
pn  libdigest-whirlpool-perl  none
ii  liburi-perl   1.60-1
ii  libwww-perl   6.04-1
ii  powermgmt-base1.31
pn  tripwire  none

[1] 
+ test 0 -eq 1
+ print rkh-ksh-string-test
+ [  = rkh-ksh-string-test ]
+ [ 0 -eq 1 ]
+ MYSHELL=/bin/sh
+ test -h /bin/sh
+ readlink /bin/sh
+ MYSHELL=dash
+ basename dash
+ MYSHELL=dash
+ test -z dash
+ echo -e rkh-ksh\tstring-test
+ [ -e rkh-ksh  string-test = rkh-ksh   string-test ]
+ ECHOOPT=
+ echo -n -e rkh-ksh-string-test
+ [ -e rkh-ksh-string-test = rkh-ksh-string-test ]
+ echo -e rkh-ksh-string-test\c
+ [ -e rkh-ksh-string-test = rkh-ksh-string-test ]
+ echo rkh-ksh-string-test\c
+ [ rkh-ksh-string-test = rkh-ksh-string-test ]
+ ECHON=c
+ head -n 1
+ HEAD_OPT=-n 
+ tail -n 1
+ TAIL_OPT=-n 
+ [ 1 -eq 1 -a dash = ksh ]
+ trap - 13
+ PROGRAM_NAME=Rootkit Hunter
+ PROGRAM_version=1.4.0
+ PROGRAM_copyright_owner=Michael Boelen
+ PROGRAM_copyright=Copyright (c) 2003-2012, Michael Boelen
+ PROGRAM_blurb=
Currently under active development by the Rootkit Hunter project team.
Please review your rkhunter.conf before using.
Please review the documentation before posting bug reports or questions.
To report bugs, obtain updates, or provide patches or comments, please go to:
http://rkhunter.sourceforge.net

To ask questions about rkhunter, please use the rkhunter-users mailing list.
Note this is a moderated list: please subscribe before posting.

Rootkit Hunter comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it under the
terms of the GNU General Public License. See the LICENSE file for details.

+ PROGRAM_license=
Rootkit Hunter 1.4.0, Copyright (c) 2003-2012, Michael Boelen

Currently under active development by the Rootkit Hunter project team.
Please review your rkhunter.conf before using.
Please review the documentation before posting bug reports or questions.
To report bugs, obtain updates, or provide patches or comments, please go to:
http://rkhunter.sourceforge.net

To ask questions about rkhunter, please use the rkhunter-users mailing list.
Note this is a moderated list: please subscribe before posting.

Rootkit Hunter comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it under the
terms of the GNU General Public License. See the LICENSE file for details.


+ CRONJOB=0
+ CHECK=0
+ CATLOGFILE=0
+ NOLOG=0
+ RKHLOGFILE=
+ DFLT_LOGFILE=/var/log/rkhunter.log
+ APPEND_LOG=0
+ APPEND_OPT=0
+ COPY_LOG_ON_ERROR=0
+ USE_SYSLOG=
+ SYSLOG_DFLT_PRIO=authpriv.notice
+ NOMOW=0
+ MAILONWARNING=
+ HASH_FUNC=
+ OLD_HASH_FUNC=
+ 

Bug#723024: caff: fails if stdin is not a TTY

2013-09-15 Thread Julius Seemayer
Package: signing-party
Version: 1.1.4-1
Severity: normal
Tags: patch

caff  from  package  signing-party  tries to read the send mail to xyz? (and
other)  answers  from  stdin,  which  is not necessary but breaks the usage of
xargs or similar tools:

(simulated, ^\.\.\.$ means cropped line(s))
$ caff  /dev/null

[NOTICE] Import failed for: .
Some keys could not be imported - continue anyway? [y/N] 

End of STDIN reached.  Are you using xargs?  Caff wants to read from STDIN,
so you can't really use it with xargs.  A patch against caff to read from
the terminal would be appreciated.
For now instead of   cat keys | xargs caff  do  caff `cat keys`
$ 

This  is pretty annoying because usually you don't have any y/n prompts before
the  mail signatures  part  is running. This means that you have to re-check
all the signatures made in that session so far.

I'd suggest to read from /dev/tty instead, like the gpg shell does. A patch to
accomplish that would look like:

--- /usr/bin/caff   2011-11-01 20:01:39.0 +0100
+++ /tmp/tmp.EQNI9gJkxx/caff2013-09-15 15:21:40.388893938 +0200
@@ -649,6 +649,8 @@
 
-   $answer = STDIN;
+   open TTY, /dev/tty or die(Cannot open TTY: $!\n);
+   $answer = TTY;
+   close TTY;
if (!defined $answer) {
$OUTPUT_AUTOFLUSH = 1;
-   die \n\n.
+   die \n\n. # XXX obsolte?
End of STDIN reached.  Are you using xargs?  Caff 
wants to read from STDIN,\n.

I'm  no  Perl  guru, so I'm not sure if that patch will have side effects. But
alternatively  caff could/should warn the user at the very beginning, which is
to be accomplished with that second patch:

--- /usr/bin/caff   2011-11-01 20:01:39.0 +0100
+++ /tmp/tmp.EQNI9gJkxx/caff2013-09-15 15:21:40.388893938 +0200
@@ -1110,2 +1112,4 @@
 
+mywarn(stdin is not a TTY, don't use xargs if you do (caff will explode 
later)) unless (-t STDIN);
+
 for my $hashkey (qw{local-user no-download no-sign no-mail mail 
keys-from-gnupg}) {

That would look like:

(again, simulated; note the [WARN] line)
$ /tmp/tmp.EQNI9gJkxx/caff  /dev/null
[WARN] stdin is not a TTY, don't use xargs if you do (caff will explode later)

[NOTICE] Import failed for: .
Some keys could not be imported - continue anyway? [y/N] 

End of STDIN reached.  Are you using xargs?  Caff wants

$ 

I'd  suggest  to  /check/ and apply the first patch only; if unsure, ignore it
and apply only the second one.


Cheers,

Julius



-- System Information:
Debian Release: 7.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages signing-party depends on:
ii  gnupg  1.4.12-7+deb7u1
ii  libc6  2.13-38
ii  libclass-methodmaker-perl  2.18-1+b1
ii  libgnupg-interface-perl0.45-1
ii  libmailtools-perl  2.09-1
ii  libmime-tools-perl 5.503-1
ii  libterm-readkey-perl   2.30-4+b2
ii  libtext-template-perl  1.45-2
ii  perl   5.14.2-21
ii  qprint 1.0.dfsg.2-2

Versions of packages signing-party recommends:
ii  dialog 1.1-20120215-2
pn  libgd-gd2-noxpm-perl | libgd-gd2-perl  none
ii  libpaper-utils 1.1.24+nmu2
ii  libtext-iconv-perl 1.7-5
ii  postfix [mail-transport-agent] 2.9.6-2
ii  whiptail   0.52.14-11.1

Versions of packages signing-party suggests:
ii  imagemagick8:6.7.7.10-5+deb7u2
ii  mutt   1.5.21-6.2
ii  texlive-latex-recommended  2012.20120611-5
pn  wipe   none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#718366: ValueError: invalid literal for int() with base 10 in xrandr.py

2013-07-30 Thread Julius Seemayer
Package: arandr
Version: 0.1.6-1
Severity: normal

Note: The given code area (xrandr.py:150) has changed in unstable, so this bug
is probably only relevant for Wheezy.


cvt(1)  suggest  mode  line names with a dot in it, which seems to make arandr
explode. No GUI window is shown, output see below:

$ xrandr # (I used xrandr --newmode/--addmode before, using the dot name)

CRT1 connected 1360x768+0+0 (normal left inverted right x axis y axis) 760mm x 
450mm

   1368x768_60.00   59.9  
$ arandr
Traceback (most recent call last):
  File /usr/bin/arandr, line 42, in module
main()
  File /usr/lib/python2.7/dist-packages/screenlayout/gui.py, line 318, in main
force_version=options.force_version
  File /usr/lib/python2.7/dist-packages/screenlayout/gui.py, line 159, in 
__init__
self.filetemplate = self.widget.load_from_x()
  File /usr/lib/python2.7/dist-packages/screenlayout/widget.py, line 93, in 
load_from_x
self._xrandr.load_from_x()
  File /usr/lib/python2.7/dist-packages/screenlayout/xrandr.py, line 150, in 
load_from_x
o.modes.append(Size(int(a) for a in d.strip().split( )[0].split(x)))
  File /usr/lib/python2.7/dist-packages/screenlayout/auxiliary.py, line 53, 
in __new__
arg = tuple(arg)
  File /usr/lib/python2.7/dist-packages/screenlayout/xrandr.py, line 150, in 
genexpr
o.modes.append(Size(int(a) for a in d.strip().split( )[0].split(x)))
ValueError: invalid literal for int() with base 10: '768_60.00'
$ 

As  mentioned  above: Probably the unstable package is not broken in that way.
I didn't figure out if this can be smoothly installed in stable.


Cheers,

Julius



-- Package-specific info:
Output of /usr/share/bug/arandr:
$ xrandr --version
xrandr program version   1.3.5
Server reports RandR version 1.3

-- System Information:
Debian Release: 7.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages arandr depends on:
ii  python 2.7.3-4
ii  python-gtk22.24.0-3+b1
ii  python2.6  2.6.8-1.1
ii  python2.7  2.7.3-6
ii  x11-xserver-utils  7.7~3

arandr recommends no packages.

arandr suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#714806: debian/README.keyctl: outdated documentation (single threaded kernel support)

2013-07-02 Thread Julius Seemayer
Package: cryptsetup
Version: 2:1.6.1-1
Severity: minor

The  documentation in /usr/share/doc/cryptsetup/README.keyctl consists a large
paragraph  about  how  to  work around the single threaded implementation of
dm-crypt in Linux.  However, that's not correct anymore as of 2.6.38, see [1],
patch  [2].   So  the  information  given in that file is wrong for Wheezy and
newer.

README.keyctl is equal in Wheezy, Jessy and Sid.


Cheers,

Julius



[1] 
http://kernelnewbies.org/Linux_2_6_38#head-49f5f735853f8cc7c4d89e5c266fe07316b49f4c
[2] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c029772125594e31eb1a5ad9e0913724ed9891f2


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#696500: martian-modem-source: Building with m-a ends with not successful

2013-06-25 Thread Julius Seemayer
Hi,


I  can  confirm  this bug.  martian-modem fails to build a working setup using
m-a  when running a 2.6 kernel.  It installs a martian_dev.o (not .ko), as we
see in the output (quote from Yvos attachement):

 dh_install source/martian_dev.o lib/modules/3.2.0-4-686-pae/extra

which leads to debian/rules

 84 dh_install source/martian_dev.$ko lib/modules/$(KVERS)/extra

while the make-style variable $k is set at

 72 k = $(shell echo $(KVERS) | grep -q ^2.6  echo k)

Obvisiously  it's a too dumb check, 3.x kernels are detected as 2.4 ones and
get .o kernel modules (which aren't recognized).

A  a  quick  fix, one  can  temporary  put  a  grep(1)  wrapper  to
/usr/local/sbin/grep:

 #!/bin/sh
 [ $1 = -q -a $2 = '^2.6' ]  return 0 || /bin/grep $@

or just fix the package itself. 


Cheers,

Julius


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#679650: paste.debian.net fails without explanation

2013-05-15 Thread Julius Seemayer
Package: pastebinit
Version: 1.3-4
Followup-For: Bug #679650

Hi,


I can confirm this bug. Plus, there is another aspect of the same issue that 
didn't get
mentioned.

paste.debian.net currently blocks submissions with less than 3 or two line 
breaks. So a
simple

$ date | pastebinit
http://paste.debian.net/
$ echo $?
0
$

fails silently. The server response includes the error message

BEGIN
div class=status 
Could not add your entry to the paste database:brbr
bThanks to some spammers you need to provide at least 3 or two 
linebreaks/bbr

/div
END

but the end user will never see it. That's the same behavior as for very long
input:

$ dd if=/dev/zero bs=10M count=1 | pastebinit
1+0 records in
1+0 records out
10485760 bytes (10 MB) copied, 0.0771713 s, 136 MB/s
http://paste.debian.net/
$ echo $?
0
$

on which reason the bug originally was reported. It creates the same kind of
silent error message as above:

BEGIN
div class=status 
Could not add your entry to the paste database:brbr
bLength of code is not allowed to exceed 150kB/bbr

/div
END

As a quick fix one could compare the defaultPB variable with the returned URL
from the server.


Cheers,

Julius



-- System Information:
Debian Release: 7.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages pastebinit depends on:
ii  python2.7.3-4
ii  python-configobj  4.7.2+ds-4

Versions of packages pastebinit recommends:
ii  lsb-release  4.1+Debian8

pastebinit suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#699711: molly-guard: fails with `Unterminated quoted string' when using a quoted shutdown(8) `warning message'

2013-02-03 Thread Julius Seemayer
Package: molly-guard
Version: 0.4.5-1
Severity: important
Tags: patch

molly-guard  will  not  work  when  using  the  optional `warning message' for
shutdown(8) that contains ``special'' charakters like ticks:

# shutdown -h +20 we'll pull the power cord soon
eval: 1: Syntax error: Unterminated quoted string
# 

A patch to make this work could look like [1]. We replace any `' in the input
by `\', after working around the broken `echo'. Each $arg can then safely get
enclosed by `' and put into $CMDARGS.


Cheers,

Julius



-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages molly-guard depends on:
ii  procps  1:3.3.3-2

molly-guard recommends no packages.

molly-guard suggests no packages.

-- no debconf information


[1] patch

$ diff -U3 /{tmp/molly-guard_0.4.4-2_all/,}usr/share/molly-guard/shutdown
--- /tmp/molly-guard_0.4.4-2_all/usr/share/molly-guard/shutdown 2008-07-01 
16:09:47.0 +0200
+++ /usr/share/molly-guard/shutdown 2013-02-03 23:31:57.0 +0100
@@ -71,7 +71,7 @@
 --) END_OF_ARGS=1;;
 *) 
   if [ $END_OF_ARGS -eq 0 ]; then
-CMDARGS=${CMDARGS:+$CMDARGS }$arg
+CMDARGS=${CMDARGS:+$CMDARGS }\$(echo X$arg | sed -e 's/^X//' -e 
's//\\/g')\
   else
 SCRIPTARGS=${SCRIPTARGS:+$SCRIPTARGS }--arg $arg
   fi
$ 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#698436: microcom: man page markup errors

2013-01-18 Thread Julius Seemayer
Package: microcom
Version: 2012.06.0-2
Severity: normal
Tags: patch

Current microcom(1) man page in testing (equal version as in Sid) has somewhat
broken man markup (see patch). Escpecially the second case is serious, because
the  escaping key sequence will be mistaken as ^- instead of ^\ in the current
version.

Patch:

$ zcat /usr/share/man/man1/microcom.1.gz | diff -U0 - /tmp/microcom.1
--- -   2013-01-18 15:05:02.035779491 +0100
+++ /tmp/microcom.1 2013-01-18 15:04:58.033396951 +0100
@@ -6 +6 @@
-\fBmicrocom\fR [\fB-p \fIdevfile\fR\fP]  [\fB-s \fIspeed\fR\fP]  [\fB-t 
\fIhost:port\fR\fP]  [\fB-c \fIinterface:rx_id:tx_id\fR\fP]  
+\fBmicrocom\fR [\fB-p \fIdevfile\fR]  [\fB-s \fIspeed\fR]  [\fB-t 
\fIhost\fR:\fIport\fR]  [\fB-c \fIinterface\fR:\fIrx_id\fR:\fItx_id\fR]  
@@ -22 +22 @@
-The default escape character is crtl-\. You may enter the 
+The default escape character is crtl-\e. You may enter the 
$ 


Cheers,

Julius



-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages microcom depends on:
ii  libc6 2.13-37
ii  libreadline6  6.2+dfsg-0.1

microcom recommends no packages.

microcom suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#696706: bash: Typo in bash(1): postition

2012-12-26 Thread Julius Seemayer
Package: bash
Version: 4.2-4
Severity: minor
Tags: patch

Current  bash(1)  manpage  in  testing  (and  also  Sid) comes with a spelling
mistake in HISTORY EXPANSION section.

Patch:

$ zcat /usr/share/man/man1/bash.1.gz | diff -U0 - /tmp/bash.1
--- -   2012-12-26 09:18:27.301641450 +0100
+++ /tmp/bash.1 2012-12-26 09:17:42.459111366 +0100
@@ -6423 +6423 @@
-Refer to the most recent command preceding the current postition in the
+Refer to the most recent command preceding the current position in the
$


Cheers,

Julius



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages bash depends on:
ii  base-files   6.11
ii  dash 0.5.7-3
ii  debianutils  4.3.2
ii  libc62.13-37
ii  libtinfo55.9-10

Versions of packages bash recommends:
ii  bash-completion  1:2.0-1

Versions of packages bash suggests:
pn  bash-doc  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#693345: apticron: /etc/cron.daily/apticron dies with timeout message

2012-11-15 Thread Julius Seemayer
Package: apticron
Version: 1.1.42
Severity: normal

apticron dies when it should check for updates, the cron mail reads like [1].
(note that I'm replacing the hostname with hostname and the FQDN with fqdn.)

I'm using apt-cacher-ng on another box B to cache Debian packages, this machine
called A has the issue. Another machine C, which uses also B for caching has
very same issues. On B itself, apticron seems to work well (!).
So one would assume apt-cacher-ng makes it fail, but a forth box D which does
NOT use the cacher, fails also.

The last useful new package there mail by apticron was on 2012-09-30 (it says
libc update, maybe relevant?). From 2012-10-03 on the cron mails came instead.

I'm glad to know how to debug further.


Cheers,

Julius


-- System Information:
Debian Release: 6.0.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages apticron depends on:
ii  apt0.8.10.3+squeeze1 Advanced front-end for dpkg
ii  bsd-mailx [mailx]  8.1.2-0.20100314cvs-1 simple mail user agent
ii  cron   3.0pl1-116process scheduling daemon
ii  debconf [debconf-2 1.5.36.1  Debian configuration management sy
ii  ucf3.0025+nmu1   Update Configuration File: preserv

Versions of packages apticron recommends:
ii  apt-listchanges  2.85.7+squeeze1 package change history notificatio
ii  iproute  20100519-3  networking and traffic control too

apticron suggests no packages.

-- debconf information:
  apticron/notification: root


[1] cron mail

Subject: Cron root@hostname test -x /usr/sbin/anacron || ( cd /  
run-parts --report /etc/cron.daily )
Content-Type: text/plain; charset=UTF-8
X-Cron-Env: SHELL=/bin/sh
X-Cron-Env: PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
X-Cron-Env: HOME=/root
X-Cron-Env: LOGNAME=root
Message-Id: 20121115052851.3A203380BA@fqdn
Date: Thu, 15 Nov 2012 06:28:51 +0100 (CET)

/etc/cron.daily/apticron:
W: Failed to fetch 
http://ftp.de.debian.org/debian/dists/squeeze/main/source/Sources.gz  500  
Connection failure: Connection timed out

W: Failed to fetch 
http://ftp.de.debian.org/debian/dists/squeeze/main/binary-amd64/Packages.gz  
500  Connection failure: Connection timed out

W: Failed to fetch 
http://ftp.de.debian.org/debian/dists/squeeze-updates/main/binary-amd64/Packages.gz
  500  Connection failure: Connection timed out

E: Some index files failed to download, they have been ignored, or old ones 
used instead.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#690521: xxxterm: X Window System errror, dies with 'BadAlloc (insufficient resources for operation)'

2012-10-15 Thread Julius Seemayer
Package: xxxterm
Version: 1:1.11.3-1
Severity: important

Steps to reproduce:

1) start xxxterm
2) do anything, e.g. click right on the empty main tab and select 'Inspect
   Element'
3) xxxterm dies with code 1, leaving the message:
   xxxterm: config_parse: cannot open /home/myuser/.xxxterm.conf: No such 
file or directory
   The program 'xxxterm' received an X Window System error.
   This probably reflects a bug in the program.
   The error was 'BadAlloc (insufficient resources for operation)'.
 (Details: serial 1328 error_code 11 request_code 53 minor_code 0)
 (Note to programmers: normally, X errors are reported asynchronously;
  that is, you will receive the error a while after causing it.
  To debug your program, run it with the --sync command line
  option to change this behavior. You can then get a meaningful
  backtrace from your debugger if you break on the gdk_x_error() function.)

(note I'm replacing my login name with myuser)

Running with --sync prevents from crashing there.

I'm a little confused, xxxterm runs on another Wheezy box, amd64, without
abnormality. I'm not sure what additional Information I could provide.

Using the source package gives the same behavior, running in gdb without
anything, with break on gdk_x_error() and finally with --sync gives:

$ gdb linux/xxxterm
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /home/myuser/tmp/xxxterm-1.11.3/linux/xxxterm...done.
(gdb) r
Starting program: /home/myuser/tmp/xxxterm-1.11.3/linux/xxxterm 
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/i386-linux-gnu/libthread_db.so.1.
xxxterm: config_parse: cannot open /home/myuser/.xxxterm.conf: No such file 
or directory
[New Thread 0xb341ab70 (LWP 11833)]
[New Thread 0xb2af2b70 (LWP 11834)]
[New Thread 0xb22ddb70 (LWP 11835)]
[New Thread 0xb1addb70 (LWP 11836)]
[New Thread 0xad309b70 (LWP 11837)]
[New Thread 0xac60db70 (LWP 11839)]
[New Thread 0xabe05b70 (LWP 11840)]
[New Thread 0xab605b70 (LWP 11841)]
[New Thread 0xaae05b70 (LWP 11842)]
[New Thread 0xaa605b70 (LWP 11843)]
[New Thread 0xa9e05b70 (LWP 11844)]
[New Thread 0xa94e4b70 (LWP 11845)]
[New Thread 0xa8ce4b70 (LWP 11846)]
[New Thread 0xa84e4b70 (LWP 11847)]
[New Thread 0xa7ce4b70 (LWP 11848)]
[New Thread 0xa6f6eb70 (LWP 11849)]
[Thread 0xac60db70 (LWP 11839) exited]
[New Thread 0xac60db70 (LWP 11850)]
[Thread 0xaa605b70 (LWP 11843) exited]
[Thread 0xab605b70 (LWP 11841) exited]
[Thread 0xabe05b70 (LWP 11840) exited]
[Thread 0xac60db70 (LWP 11850) exited]
[Thread 0xaae05b70 (LWP 11842) exited]
[Thread 0xa8ce4b70 (LWP 11846) exited]
[Thread 0xa7ce4b70 (LWP 11848) exited]
[Thread 0xa84e4b70 (LWP 11847) exited]
[Thread 0xa94e4b70 (LWP 11845) exited]
[New Thread 0xa94e4b70 (LWP 11851)]
[New Thread 0xa84e4b70 (LWP 11852)]
[New Thread 0xa7ce4b70 (LWP 11853)]
The program 'xxxterm' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 1432 error_code 11 request_code 53 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
[Thread 0xa7ce4b70 (LWP 11853) exited]
[Thread 0xa84e4b70 (LWP 11852) exited]
[Thread 0xa94e4b70 (LWP 11851) exited]
[Thread 0xa6f6eb70 (LWP 11849) exited]
[Thread 0xa9e05b70 (LWP 11844) exited]
[Thread 0xad309b70 (LWP 11837) exited]
[Thread 0xb1addb70 (LWP 11836) exited]
[Thread 0xb22ddb70 (LWP 11835) exited]
[Thread 0xb2af2b70 (LWP 11834) exited]
[Thread 0xb341ab70 (LWP 11833) exited]
[Inferior 1 (process 11830) exited with code 01]
(gdb) b gdk_x_error
Function gdk_x_error not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (gdk_x_error) pending.
(gdb) r
Starting program: /home/myuser/tmp/xxxterm-1.11.3/linux/xxxterm 
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/i386-linux-gnu/libthread_db.so.1.
xxxterm: config_parse: cannot open /home/myuser/.xxxterm.conf: No such file 
or directory
[New Thread 0xb341ab70 (LWP 11860)]
[New Thread 0xb2af2b70 (LWP 11861)]
[New Thread 0xb22ddb70 (LWP 11862)]
[New Thread 0xb1addb70 (LWP 11863)]
[New Thread 0xad309b70 (LWP 11865)]
[New Thread 0xac60db70 (LWP 11866)]
[New Thread 0xabe05b70 (LWP 11867)]
[New Thread 0xab605b70 (LWP 11868)]