Bug#1068463: procyon: Untrusted code execution via cwd in classpath

2024-04-05 Thread Tomas Tintera
Package: procyon-decompiler
Version: 0.6.0-1
Tags: security
Severity: grave

In the default configuration, procyon prepends current working directory
to the java classpath.
This is done in the shell script /usr/bin/procyon, which sets, apparently
by mistake, CLASSPATH=$CLASSPATH:..., where $CLASSPATH is a usually
empty environment variable - and empty string in this context is
interpreted as a current working directory by java.

This is potentially dangerous, especially with a decompiler, which is
supposed to deal with untrusted code. In a possible bad scenario, a user
(without CLASSPATH environment variable, which is the debian default)
might try to decompile an untrusted malicious jar:

wget ".../bad.jar"
jar xf bad.jar
procyon ...

Regardless of what command line arguments are given to procyon,
if the extracted jar contained e.g. the jcommander class, then
it will get executed.



Bug#1004837: XFCE Window Buttons not visible after Debian upgrade

2022-04-28 Thread Tomas Tintera
Hi,

Apologies, the debdiff I just sent have wrong date info in a patch tag.
The patch currently attached should be ok.

With regards,
Tomas "trosos" Tinteradiff -Nru xfce4-panel-4.16.2/debian/changelog xfce4-panel-4.16.2/debian/changelog
--- xfce4-panel-4.16.2/debian/changelog	2021-02-27 17:29:44.0 +0100
+++ xfce4-panel-4.16.2/debian/changelog	2022-04-28 16:20:27.0 +0200
@@ -1,3 +1,10 @@
+xfce4-panel (4.16.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix upstream bug #188: some windows do not appear in the panel.
+
+ -- Tomas Tintera   Thu, 28 Apr 2022 16:20:27 +0200
+
 xfce4-panel (4.16.2-1) unstable; urgency=medium
 
   * New upstream version 4.16.2
diff -Nru xfce4-panel-4.16.2/debian/patches/series xfce4-panel-4.16.2/debian/patches/series
--- xfce4-panel-4.16.2/debian/patches/series	2021-02-27 17:29:44.0 +0100
+++ xfce4-panel-4.16.2/debian/patches/series	2022-04-28 16:20:27.0 +0200
@@ -1,2 +1,3 @@
 01_support-non-multiarch-modules.patch
 02_pager-size-for-viewport.patch
+03_disconnect-size-allocate.patch
diff -Nru xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch
--- xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch	1970-01-01 01:00:00.0 +0100
+++ xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch	2022-04-28 16:20:27.0 +0200
@@ -0,0 +1,46 @@
+Origin: upstream, https://gitlab.xfce.org/xfce/xfce4-panel/-/merge_requests/66/diffs
+Date: Thu, 28 Apr 2022 16:20:27 +0200
+Subject: Fix some window buttons not appearing in the panel
+
+This is a backport of an upstream fix to odd behavior of the tasklist widget
+where closing a window would not reposition remaining window buttons and/or
+where new window buttons would not appear.
+
+Bug-Debian: https://bugs.debian.org/1004837
+Bug: https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/188
+Applied-Upstream: https://gitlab.xfce.org/xfce/xfce4-panel/-/commit/9881894b9588d36da69901f15215009c8debf1ac
+
+---
+
+--- xfce4-panel-4.16.2.orig/plugins/tasklist/tasklist-widget.c
 xfce4-panel-4.16.2/plugins/tasklist/tasklist-widget.c
+@@ -2871,20 +2871,6 @@ xfce_tasklist_button_geometry_changed2 (
+ 
+ 
+ 
+-static gboolean
+-xfce_tasklist_button_size_allocate (GtkWidget *widget,
+-GdkRectangle  *allocation,
+-gpointer   user_data)
+-{
+-  XfceTasklistChild *child = user_data;
+-  /* Make sure the icons have the correct size */
+-  xfce_tasklist_button_icon_changed (child->window, child);
+-
+-  return TRUE;
+-}
+-
+-
+-
+ #ifdef GDK_WINDOWING_X11
+ static void
+ xfce_tasklist_button_geometry_changed (WnckWindow*window,
+@@ -3560,8 +3546,6 @@ xfce_tasklist_button_new (WnckWindow   *
+   G_CALLBACK (xfce_tasklist_button_button_release_event), child);
+ 
+   /* monitor window changes */
+-  g_signal_connect (G_OBJECT (child->button), "size-allocate",
+-  G_CALLBACK (xfce_tasklist_button_size_allocate), child);
+   g_signal_connect (G_OBJECT (window), "icon-changed",
+   G_CALLBACK (xfce_tasklist_button_icon_changed), child);
+   g_signal_connect (G_OBJECT (window), "name-changed",


Bug#1004837: XFCE Window Buttons not visible after Debian upgrade

2022-04-28 Thread Tomas Tintera
Control: tags -1 + patch
Control: tags -1 + fixed-upstream

Hi maintainer,

having the same upgrade experience as the original poster, this prevents me
from promoting users to upgrade yet.

This is probably an upstream bug #188, which has been fixed this February:
https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/188

Could you please backport the upstream fix, as in the provided debpatch?


Best regards,
Tomasdiff -Nru xfce4-panel-4.16.2/debian/changelog xfce4-panel-4.16.2/debian/changelog
--- xfce4-panel-4.16.2/debian/changelog	2021-02-27 17:29:44.0 +0100
+++ xfce4-panel-4.16.2/debian/changelog	2022-04-28 16:20:27.0 +0200
@@ -1,3 +1,10 @@
+xfce4-panel (4.16.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix upstream bug #188: some windows do not appear in the panel.
+
+ -- Tomas Tintera   Thu, 28 Apr 2022 16:20:27 +0200
+
 xfce4-panel (4.16.2-1) unstable; urgency=medium
 
   * New upstream version 4.16.2
diff -Nru xfce4-panel-4.16.2/debian/patches/series xfce4-panel-4.16.2/debian/patches/series
--- xfce4-panel-4.16.2/debian/patches/series	2021-02-27 17:29:44.0 +0100
+++ xfce4-panel-4.16.2/debian/patches/series	2022-04-28 16:20:27.0 +0200
@@ -1,2 +1,3 @@
 01_support-non-multiarch-modules.patch
 02_pager-size-for-viewport.patch
+03_disconnect-size-allocate.patch
diff -Nru xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch
--- xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch	1970-01-01 01:00:00.0 +0100
+++ xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch	2022-04-28 16:20:27.0 +0200
@@ -0,0 +1,46 @@
+Origin: upstream, https://gitlab.xfce.org/xfce/xfce4-panel/-/merge_requests/66/diffs
+Date: Thu, 31 Oct 2019 17:20:31 +0100
+Subject: Fix some window buttons not appearing in the panel
+
+This is a backport of an upstream fix to odd behavior of the tasklist widget
+where closing a window would not reposition remaining window buttons and/or
+where new window buttons would not appear.
+
+Bug-Debian: https://bugs.debian.org/1004837
+Bug: https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/188
+Applied-Upstream: https://gitlab.xfce.org/xfce/xfce4-panel/-/commit/9881894b9588d36da69901f15215009c8debf1ac
+
+---
+
+--- xfce4-panel-4.16.2.orig/plugins/tasklist/tasklist-widget.c
 xfce4-panel-4.16.2/plugins/tasklist/tasklist-widget.c
+@@ -2871,20 +2871,6 @@ xfce_tasklist_button_geometry_changed2 (
+ 
+ 
+ 
+-static gboolean
+-xfce_tasklist_button_size_allocate (GtkWidget *widget,
+-GdkRectangle  *allocation,
+-gpointer   user_data)
+-{
+-  XfceTasklistChild *child = user_data;
+-  /* Make sure the icons have the correct size */
+-  xfce_tasklist_button_icon_changed (child->window, child);
+-
+-  return TRUE;
+-}
+-
+-
+-
+ #ifdef GDK_WINDOWING_X11
+ static void
+ xfce_tasklist_button_geometry_changed (WnckWindow*window,
+@@ -3560,8 +3546,6 @@ xfce_tasklist_button_new (WnckWindow   *
+   G_CALLBACK (xfce_tasklist_button_button_release_event), child);
+ 
+   /* monitor window changes */
+-  g_signal_connect (G_OBJECT (child->button), "size-allocate",
+-  G_CALLBACK (xfce_tasklist_button_size_allocate), child);
+   g_signal_connect (G_OBJECT (window), "icon-changed",
+   G_CALLBACK (xfce_tasklist_button_icon_changed), child);
+   g_signal_connect (G_OBJECT (window), "name-changed",


Bug#821403: Version of libssl-dev in Build-depends

2016-04-18 Thread Tomas Tintera
Source: nodejs
Version: 4.4.3~dfsg-1
Severity: minor

Hi,

The source package build-depends on libssl-dev (>= 1.0.0g), while it
actually needs at least 1.0.2 to compile.

According to the maintainer Jeremy Lal:
> [SSL_CTX_add1_chain_cert] has been added in openssl 1.0.2
(from a response to #815272)

Please, correct the Build-depends.


With regards,
Tomas "trosos" Tintera


Bug#703684: cadabra: Left-arrow in terminal

2014-01-11 Thread Tomas Tintera
Hi. According to the referrence guide at
http://cadabra.phi-sci.com/cadabra.pdf , cadabra should be run using
the prompt cadabra command. This provides canabra with command-line
editing features, along with the command history.


Bestr regards,
Tomas trosos Tintera


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



Bug#509238: some more logs

2010-08-25 Thread Tomas Tintera
Hi,

I have the same problem with my TC-261MXI (mini PC) and I managed to get
more logs which seem to be informative.

I also booted from USB. I used syslinux with kernel and initrd from
http://http.us.debian.org/debian/dists/lenny/main/installer-i386/current/images/netboot/debian-installer/i386/

But the workaround with vga=771 does not work for me (I got larger
display, but panic still occurs).

I tried to get some more info from syslogd:

I booted with the following kernel parameters (immitating expert mode)
priority=low vga=normal initrd=initrd.gz
Then I switched to VT2 and started debugging to the second partition on
USB disk:
tail -n+1 -f /var/log/syslog  /dev/sda2

I confirmed to configure network devices and to start PC card services.
I confirmed to use DHCP to autoconfigure the network and the progress
bar went slowly to 100%. At that point, kernel panic usually happens.
Alternatively, the dialog is shown, saying that autoconfiguring via DHCP
failed. If I confirm to continue, kernel panic occurs; alternatively,
kernel panic sometimes occurs in about 30 secs without me confirming to
countinue.

Unfortunately, I managed to capture syslogd messages only to the stage
before I confirmed to use DHCP (and after it completes network device
configuration). There were many lines of messages on VT4 just before the
panic, but unfortunately this version of tail is not able to log in
shorter intervals than 1 sec.

But the line saying kernel BUG at include/linux/netdevice.h:431! could
be informative, I think.
Attached is the output of lspci -vvv and the content
of /var/log/syslog 1 sec. before the panic.


Best regards,
Tomas trosos Tintera

Aug 25 20:27:38 syslogd started: BusyBox v1.10.2
Aug 25 20:27:38 kernel: klogd started: BusyBox v1.10.2 (Debian 1:1.10.2-2)
Aug 25 20:27:38 kernel: [0.00] Initializing cgroup subsys cpu
Aug 25 20:27:38 kernel: [0.00] Linux version 2.6.26-2-486 (Debian 
2.6.26-23) (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 
4.1.2-25)) #1 Sat Jun 12 02:15:32 UTC 2010
Aug 25 20:27:38 kernel: [0.00] CPU: Vendor unknown, using generic init.
Aug 25 20:27:38 kernel: [0.00] CPU: Your system may be unstable.
Aug 25 20:27:38 kernel: [0.00] BIOS-provided physical RAM map:
Aug 25 20:27:38 kernel: [0.00]  BIOS-e820:  - 
0009fc00 (usable)
Aug 25 20:27:38 kernel: [0.00]  BIOS-e820: 0009fc00 - 
000a (reserved)
Aug 25 20:27:38 kernel: [0.00]  BIOS-e820: 000e4000 - 
0010 (reserved)
Aug 25 20:27:38 kernel: [0.00]  BIOS-e820: 0010 - 
2000 (usable)
Aug 25 20:27:38 kernel: [0.00]  BIOS-e820: ff00 - 
0001 (reserved)
Aug 25 20:27:38 kernel: [0.00] 512MB LOWMEM available.
Aug 25 20:27:38 kernel: [0.00] Entering add_active_range(0, 0, 131072) 
0 entries of 256 used
Aug 25 20:27:38 kernel: [0.00] Zone PFN ranges:
Aug 25 20:27:38 kernel: [0.00]   DMA 0 - 4096
Aug 25 20:27:38 kernel: [0.00]   Normal   4096 -   131072
Aug 25 20:27:38 kernel: [0.00] Movable zone start PFN for each node
Aug 25 20:27:38 kernel: [0.00] early_node_map[1] active PFN ranges
Aug 25 20:27:38 kernel: [0.00] 0:0 -   131072
Aug 25 20:27:38 kernel: [0.00] On node 0 totalpages: 131072
Aug 25 20:27:38 kernel: [0.00]   DMA zone: 32 pages used for memmap
Aug 25 20:27:38 kernel: [0.00]   DMA zone: 0 pages reserved
Aug 25 20:27:38 kernel: [0.00]   DMA zone: 4064 pages, LIFO batch:0
Aug 25 20:27:38 kernel: [0.00]   Normal zone: 992 pages used for memmap
Aug 25 20:27:38 kernel: [0.00]   Normal zone: 125984 pages, LIFO 
batch:31
Aug 25 20:27:38 kernel: [0.00]   Movable zone: 0 pages used for memmap
Aug 25 20:27:38 kernel: [0.00] DMI not present or invalid.
Aug 25 20:27:38 kernel: [0.00] ACPI Error (tbxfroot-0218): A valid RSDP 
was not found [20080321]
Aug 25 20:27:38 kernel: [0.00] Allocating PCI resources starting at 
3000 (gap: 2000:df00)
Aug 25 20:27:38 kernel: [0.00] PM: Registered nosave memory: 
0009f000 - 000a
Aug 25 20:27:38 kernel: [0.00] PM: Registered nosave memory: 
000a - 000e4000
Aug 25 20:27:38 kernel: [0.00] PM: Registered nosave memory: 
000e4000 - 0010
Aug 25 20:27:38 kernel: [0.00] Built 1 zonelists in Zone order, 
mobility grouping on.  Total pages: 130048
Aug 25 20:27:38 kernel: [0.00] Kernel command line: priority=low 
vga=normal initrd=initrd.gz BOOT_IMAGE=linux 
Aug 25 20:27:38 kernel: [0.00] No local APIC present or hardware 
disabled
Aug 25 20:27:38 kernel: [0.00] mapped APIC to b000 (01403000)
Aug 25 20:27:38 kernel: [0.00] Initializing CPU#0
Aug 25 20:27:38 kernel: [0.00] PID hash table entries: 

Bug#439846: framebuffer script badly interprets modedb boot parameter

2008-08-18 Thread Tomas Tintera

tags 439846 + patch
thanks

A patch for /usr/share/initramfs-tools/scripts/init-top/framebuffer
from initramfs-tools 0.92f, which is the current unstable, is
attached.

-- 
Best regards,
Tomas trosos Tintera


On 2007-08-27 23:05 +0200, trosos wrote:
 Package: initramfs-tools
 Version: 0.85h
 
 The init-top/framebuffer script should use mode_option (according
 to the documentation) as a fb module parameter for setting the video
 mode, instead of mode.
 
 The Linux documentation uses mode_option argument:
 
  $ zcat /usr/share/doc/linux-doc-2.6.18/Documentation/fb/modedb.txt.gz
  ...
  Valid mode specifiers (mode_option argument):
  
  xresxyres[M][R][-bpp][@refresh][i][m]
  name[-bpp][@refresh]
  ...
 
 But the framebuffer script uses mode argument:
 
  $ cat /usr/share/initramfs-tools/scripts/init-top/framebuffer
  ...
  # When the options are used with modules, they need to be space-separated
  ...
  #   modevalue   - mode=modevalue
  ...
 
 As a consequence, if I specify eg. video=aty128fb:1024x768-16 as
 a kernel boot parameter, the framebuffer script uses a mode module
 parameter (instead of mode_option), which will not be understood by
 the module.
 
 I tried aty128fb and nvidiafb modules, and both accept video_mode
 option, and don't accept mode option. With other fb modules I would
 expect similar behavior.
 
 One can use video=foofb:mode_option=1024x768... as a workaround,
 but the documented behavior will not work.
 
 If no fb driver uses the mode parameter, I suggest to change the
 init-top/framebuffer script in order to use the mode_option
 parameter.
 
 ---
 
 $ uname -r
 2.6.18

--- framebuffer	2008-06-04 17:21:35.0 +0200
+++ framebuffer.new	2008-08-18 16:27:45.0 +0200
@@ -21,14 +21,15 @@
 # 1) options are comma-separated
 # 2) options can be in either of these three forms:
 #arg=value, arg:value, boolean-arg.
-# 3) the mode option has the form xresxyres[M][R][-bpp][@refresh][i][m]
-#and may or may not start with mode=
+# 3) the mode_option option has the form
+#xresxyres[M][R][-bpp][@refresh][i][m]
+#and may or may not start with mode_option=
 #
 # When the options are used with modules, they need to be space-separated
 # and the following conversions are needed:
 #	arg:value - arg=value
 #	boolean-arg - boolean-arg=1
-#	modevalue   - mode=modevalue
+#	modevalue   - mode_option=modevalue
 parse_video_opts()
 {
 	local OPTS=$1
@@ -48,7 +49,7 @@
 			echo -n ${opt%:*}=${opt#*:} 
 		# Presumably a modevalue without the mode= prefix
 		elif [ ${opt} != ${opt#[0-9]*x[0-9]} ]; then
-			echo -n mode=$opt 
+			echo -n mode_option=$opt 
 		# Presumably a boolean
 		else
 			echo -n ${opt}=1 


Bug#464938: d-i on i386 with 16 MiB RAM (using swap)

2008-02-09 Thread Tomas Tintera
Sorry, the init.diff in the report was corrupt, sending right version.


Tomas Tintera

--- smazat/init	2008-02-09 19:45:04.0 +0100
+++ a/init	2008-02-09 20:31:20.0 +0100
@@ -209,14 +209,14 @@
 
 	echo -n Loading..
 	# pipe_progress adds dots to the above line while there is
-	# activity. But we must be sure to catch errors from the zcat.
+	# activity. But we must be sure to catch errors from the micro-bunzip.
 	# Hard to do in a pipeline..
-	echo 0  /tmp/zcat_failure
+	echo 0  /tmp/bunzip_failure
 	cd mnt
-	(zcat ../floppy/initrd.gz || echo 1  /tmp/zcat_failure ) | cpio -i -V || abort failed to extract initrd (may be out of space on ram disk)
+	(micro-bunzip ../floppy/initrd.bz2 || echo 1  /tmp/bunzip_failure ) | cpio -i -V || abort failed to extract initrd (may be out of space on ram disk)
 	cd ..
 
-	if [ `cat /tmp/zcat_failure` = 0 ]; then
+	if [ `cat /tmp/bunzip_failure` = 0 ]; then
 		LOADED=1
 	else
 		echo install media seems to be bad! 2


Bug#464938: d-i on i386 with 16 MiB RAM (using swap)

2008-02-09 Thread Tomas Tintera
Package: debian-installer
Version: 20070308
Severity: wishlist
Tags: patch

d-i for i386 on floppies works currently only with
32 MiB RAM, which is unnecessarily much. (Sometimes one
needs to install Debian e.g. on 16 MiB machines.)

This number can be reduced by activating swap as soon as
possible.

Assume that the machine have a prepared swap partition.

I found how to change the d-i floppies (without increasing
its number) in order to work with 16 MiB. The changes to
apply against the current lenny's d-i floppies (which are
now almost identical to those for etch) for i386 follows:

1. We need
 ide/ide-core.ko,
 ide/ide-disk.ko and
 ide/ide-generic.ko
modules on 2nd (root) floppy (in initrd) in order to get
HDDs work. The space for it can be made by bzipping 2nd
floppy's initrd instead of gzipping it. Also the following
lines must be added to modules.dep in initrd on the 2nd
floppy:

/lib/modules/2.6.18-5-486/kernel/drivers/ide/ide-core.ko:
/lib/modules/2.6.18-5-486/kernel/drivers/ide/ide-disk.ko: 
/lib/modules/2.6.18-5-486/kernel/drivers/ide/ide-core.ko
/lib/modules/2.6.18-5-486/kernel/drivers/ide/ide-generic.ko: 
/lib/modules/2.6.18-5-486/kernel/drivers/ide/ide-core.ko

2. We need to use a bzip2 decompressor on 1st (boot) floppy
instead of zcat. We can use micro-bunzip
(http://www.landley.net/code/micro-bunzip.c (version 3.0,
which is smaller than 4.1)), with the patch in
the attachment, statically linked with klibc.

Then /bin/zcat (in initrd on 1st floppy) is useless and may
be replaced with /bin/micro-bunzip.
The file /init in initrd on 1st floppy must be changed in
order to work with micro-bunzip (the patch is in the
attachment).

3. We need to take the user the possibility to tell the
installer where the swap partition is. We can specify the
new kernel boot option (swapon= (eg. swapon=/dev/hda5)). For
that purpose, I wrote a new script for 2nd floppy which
checks that option, installs appropriate modules and
activates swap (S04swapon, in the attachment (to add in the
2nd floppy's initrd into the directory
/lib/debian-installer-startup.d,
without execution permission)).

4. We can change /lib/debian-installer-startup.d/S15lowmem
in initrd on 2nd floppy so that it takes account of swap
(patch is in the attachment).


Works fine with 16 MiB RAM, maybe also 8 MiB.

Nevertheless, d-i package seems rather complicated to me,
and I haven't found how to change it's sources in order to
produce the floppies that I described above. I would be glad
if you could make these changes to d-i or tell me what can I
do.


With regards,
Tomas trosos Tintera

--- init-orig   2008-02-09 19:45:04.0 +0100
+++ init2008-02-09 20:31:20.0 +0100
@@ -209,14 +209,14 @@

echo -n Loading..
# pipe_progress adds dots to the above line while there is
-   # activity. But we must be sure to catch errors from the zcat.
+   # activity. But we must be sure to catch errors from the micro-bunzip.
# Hard to do in a pipeline..
-   echo 0  /tmp/zcat_failure
+   echo 0  /tmp/bunzip_failure
cd mnt
-   (zcat ../floppy/initrd.gz || echo 1  /tmp/zcat_failure ) | cpio -i -V || abort failed to extract initrd (may be out of space on ram disk)
+   (micro-bunzip ../floppy/initrd.bz2 || echo 1  /tmp/bunzip_failure ) | cpio -i -V || abort failed to extract initrd (may be out of space on ram disk)cd ..

-   if [ `cat /tmp/zcat_failure` = 0 ]; then
+   if [ `cat /tmp/bunzip_failure` = 0 ]; then
LOADED=1
else
echo install media seems to be bad! 2
swapdev=
for word in $(cat /proc/cmdline); do
if [ ${word%%=*} = swapon ]; then
swapdev=${word#swapon=}
fi
done

if [ -n $swapdev ]; then
echo Trying to load generic IDE modules in order to activate swap
modprobe ide-disk /dev/null 21 || true
modprobe ide-generic /dev/null 21 || true

# Wait 30 seconds for hard disk to wake up
echo -n Waiting for $swapdev to be created ...
i=6;
while [ $i -ge 0 ]; do
if [ -b $swapdev ]; then
echo
swapon $swapdev || true
break;
fi
if [ $i = 0 ]; then
echo -e \nCould not swap on $swapdev - not a block 
device. 2
break;
fi
i=$(($i - 1))
sleep 5  # in seconds
echo -n .
done
fi
--- micro-bunzip.c-orig 2007-09-30 15:11:11.0 +0200
+++ micro-bunzip.c  2007-09-30 15:47:58.0 +0200
@@ -511,5 +511,5 @@
 int main(int argc, char *argv[])
 {
char *c=uncompressStream(0,1);
-   fprintf(stderr,\n%s\n, c ? c : Completed OK);
+   if (c) fprintf (stderr, %s\n, c);
 }
--- S15lowmem-orig 2008-02-09 19:11:45.0 +0100
+++ S15lowmem  2007-09-29 18:44:51.0 +0200
@@ -4,7 +4,11 @@
 if [ $ram =  ]; then

Bug#430375: apt-src: Allow to check build dependencies only when compiling

2007-06-23 Thread Tomas Tintera
Package: apt-src
Version: 0.25.1-0.1
Severity: wishlist

I think it would be good if apt-src could be configured to check for build
dependencies (and potentionally propose to satisfy them) only when it is
really going to compile, and not when it only downloads the source.

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=UTF-8)

Versions of packages apt-src depends on:
ii  apt 0.6.46.4-0.1 Advanced front-end for dpkg
ii  dpkg-dev1.14.4   package building tools for Debian
ii  libapt-pkg-perl 0.1.20   Perl interface to libapt-pkg
ii  perl5.8.8-7  Larry Wall's Practical Extraction 

Versions of packages apt-src recommends:
ii  build-essential   11.3   informational list of build-essent
ii  fakeroot  1.5.10 Gives a fake root environment
ii  sudo  1.6.8p12-5 Provide limited super user privile

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#427682: dpkg-reconfigure exim4-config hangs

2007-06-05 Thread Tomas Tintera
Package: exim4-base
Version: 4.63-17

If I run

dpkg-reconfigure exim4-config

and leave all questions as they are filled implicitely, it shows a
message that exim4 server is restarting, and hangs.

ps shows that the process exim4-config.config is defunct.

This happens with exim4-config.config 4.44-2. If I upgrade to 4.63-17,
it works well.

I thing there is a problem with dependencies (exim4-base 4.63-17 should
depend on some earlier version of exim4-config than =4.30).


--
trosos



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#427682: dpkg-reconfigure exim4-config hangs

2007-06-05 Thread Tomas Tintera
Oh, I am sorry, there is a problem in the exim4-config package (old
version), reported at #297607.

I apologise.

On Tue, 5.6.2007 at 21:49 +0200, Marc Haber wrote:
 On Tue, Jun 05, 2007 at 09:08:16PM +0200, Tomas Tintera wrote:
  If I run
  
  dpkg-reconfigure exim4-config
  
  and leave all questions as they are filled implicitely, it shows a
  message that exim4 server is restarting, and hangs.
  
  ps shows that the process exim4-config.config is defunct.
 
 A shellscript should not be a zombie. This sounds like a system issue
 on your side. Please export EX4DEBUG=yes and try again to see what
 fails.
 
  This happens with exim4-config.config 4.44-2.
 
 4.44-2 was never released with a Debian distribution, updates are not
 supported. otoh, I do not see any reason why an update should not work.
 
 Greetings
 Marc




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#404894: update-initramfs: zero exit status when initramfs is altered or does not exist

2006-12-29 Thread Tomas Tintera
On Fri, 29 Dec 2006 09:41 +0100, maximilian attems wrote: 
 unless you come up with a _really_ compelling arg, that wasn't presented
 yet and that supersedes aboves analysis, i'll close that bug soon.

Ok, so I think it is likely that the user overlooks this error message
if he installs more packages simultaneously (the message is shown
through stderr and may be quickly scrolled out from the terminal), but
that seems to be the problem of debconf or something so.

You can close the bug.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#404894: update-initramfs: zero exit status when initramfs is altered or does not exist

2006-12-28 Thread Tomas Tintera
Package: initramfs-tools
Version: 0.85e

I think that update-initramfs should return some non-zero error status
when trying to update a non-existing or altered initramfs.

Currently, when I am trying to configure e.g. an uswsusp package
(dpkg-reconfigure uswsusp), and have initramfs removed, the
configuration script calls update-initramfs, which does not update
anything (because of non-existing initramfs) - it only shows the error
message

/boot/initrd.img-2.6.17-2-686 does not exist. Cannot update.

(that is good) and exits with error status 0. The result is that uswsusp
is not properly configured, but dpkg-reconfigure exits with status 0 -
which should not happen, I think (I would expect dpkg-reconfigure to
exit with non-zero error status).

I suggest to use panic() instead of mild_panic() in altered_check() in
the update-initramfs script.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]