Bug#793641: A patch for libc6

2015-07-25 Thread Krzysztof A. Sobiecki
With this small patch to libc6 vlc started to work fine again.
--- glibc-2.21.orig/sysdeps/generic/ldsodefs.h
+++ glibc-2.21/sysdeps/generic/ldsodefs.h
@@ -390,7 +390,7 @@ struct rtld_global
 #define TLS_SLOTINFO_SURPLUS (62)
 
 /* Number of additional slots in the dtv allocated.  */
-#define DTV_SURPLUS	(14)
+#define DTV_SURPLUS	(64)
 
   /* Initial dtv of the main thread, not allocated with normal malloc.  */
   EXTERN void *_dl_initial_dtv;

-- 
X was an interactive protocol: 
alpha blending a full-screen image looked like slugs racing down the monitor. 
http://www.keithp.com/~keithp/talks/usenix2000/render.html


Bug#793641: vlc: unable to load avcodec plugin due to use of static TLS

2015-07-25 Thread Krzysztof A. Sobiecki
Package: vlc
Version: 2.2.1-2+b2
Severity: normal

Dear Maintainer,
While I try to play twitch streams using livestreamer I get this error:
VLC media player 2.2.1 Terry Pratchett (Weatherwax) (revision 2.2.1-0-ga425c42)
[00ec0388] core libvlc: Running vlc with the default interface. Use 
'cvlc' to use vlc without interface.
[7f2ed8c01718] ts demux: MPEG-4 descriptor not found for pid 0x100 type 0xf
[7f2ed8ca0ab8] core decoder warning: cannot load module 
`/usr/lib/vlc/plugins/codec/libavcodec_plugin.so' (dlopen: cannot load any more 
object with static TLS)
[7f2ed8ca0ab8] core decoder error: corrupt module: 
/usr/lib/vlc/plugins/codec/libavcodec_plugin.so
[7f2ed8ca0ab8] core decoder error: Codec `h264' (H264 - MPEG-4 AVC (part 
10)) is not supported.
[7f2ed8c01718] ts demux warning: first packet for pid=258 cc=0x2
[7f2ed8c01718] ts demux warning: first packet for pid=257 cc=0x7
[7f2ed8c01718] ts demux warning: first packet for pid=256 cc=0x9
[7f2ed8c99848] packetizer_mpeg4audio packetizer: AAC channels: 2 
samplerate: 48000
[7f2ed8c8f168] faad decoder warning: decoded zero sample
[7f2ed0006eb8] equalizer audio filter error: No preset selected
[00fcc5b8] core audio output error: cannot add user audio filter 
"equalizer" (skipped)
[00fcc5b8] pulse audio output warning: starting late (-11781 us)
[00fcc5b8] core audio output warning: playback too late (74910): 
up-sampling

So some libraries overuse static TLS...
I think similar bug is described here:
https://bugzilla.redhat.com/show_bug.cgi?id=1124987
so I don't really know if I should fill this bug against ffmpeg, vlc or
libc6

Stream example:
livestreamer -v http://www.twitch.tv/naughtybear_ best

Thanks.


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

Kernel: Linux 4.2.0-rc3-00115-gc5dfd65-dirty (SMP w/6 CPU cores)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: systemd (via /run/systemd/system)

Versions of packages vlc depends on:
ii  fonts-freefont-ttf  20120503-4
ii  libaa1  1.4p5-43
ii  libavcodec-ffmpeg56 7:2.7.2-1
ii  libavutil-ffmpeg54  7:2.7.2-1
ii  libc6   2.21-0experimental0
ii  libcaca00.99.beta19-2
ii  libcairo2   1.14.2-2
ii  libegl1-mesa [libegl1-x11]  10.7-git7
ii  libfreerdp-client1.11.1.0~git20140921.1.440916e+dfsg1-4
ii  libfreerdp-core1.1  1.1.0~git20140921.1.440916e+dfsg1-4
ii  libfreerdp-gdi1.1   1.1.0~git20140921.1.440916e+dfsg1-4
ii  libfreetype62.5.2-4
ii  libfribidi0 0.19.6-3
ii  libgcc1 1:5.2.1-12
ii  libgl1-mesa-glx [libgl1]10.7-git7
ii  libgles1-mesa [libgles1]10.7-git7
ii  libgles2-mesa [libgles2]10.7-git7
ii  libglib2.0-02.45.4-1
ii  libpulse0   6.0-2
ii  libqt5core5a5.5.0+dfsg-1
ii  libqt5gui5  5.5.0+dfsg-1
ii  libqt5widgets5  5.5.0+dfsg-1
ii  libqt5x11extras55.4.2-2
ii  librsvg2-2  2.40.9-2
ii  libsdl-image1.2 1.2.12-5+b5
ii  libsdl1.2debian 1.2.15-11
ii  libstdc++6  5.2.1-12
ii  libva-drm1  1.6.0-1
ii  libva-x11-1 1.6.0-1
ii  libva1  1.6.0-1
ii  libvlccore8 2.2.1-2+b2
ii  libvncclient1   0.9.10+dfsg-3
ii  libx11-62:1.6.3-1
ii  libxcb-composite0   1.10-3+b1
ii  libxcb-keysyms1 0.4.0-1
ii  libxcb-randr0   1.10-3+b1
ii  libxcb-shm0 1.10-3+b1
ii  libxcb-xv0  1.10-3+b1
ii  libxcb1 1.10-3+b1
ii  libxext62:1.3.3-1
ii  libxinerama12:1.1.3-1+b1
ii  libxpm4 1:3.5.11-1+b1
ii  vlc-nox 2.2.1-2+b2
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages vlc recommends:
ii  vlc-plugin-notify  2.2.1-2+b2
ii  vlc-plugin-samba   2.2.1-2+b2
ii  xdg-utils  1.1.0~rc1+git20111210-7.4

Versions of packages vlc suggests:
pn  videolan-doc  

Versions of packages vlc-nox depends on:
ii  liba52-0.7.4   0.7.4-18
ii  libasound2 1.0.29-1
ii  libass50.12.3-1
ii  libavahi-client3   0.6.31-5
ii  libavahi-common3   0.6.31-5
ii  libavc1394-0   0.5.4-2
ii  libavcodec-ffmpeg567:2.7.2-1
ii  libavformat-ffmpeg56   7:2.7.2-1
ii  libavutil-ffmpeg54 7:2.7.2-1
ii  libbasicusageenvironment0  2014.01.13-1
ii  libbluray1 1:0.8.1-1
ii  libc6  2.21-0experimental0
ii  libcddb2   1.3.2-5
ii  libcdio13  0.83-4.2
ii  libchro

Bug#439906: A problem, with oregano

2015-01-04 Thread Krzysztof A. Sobiecki
retitle 439906 Oregano allows to place components without models, it breaks the 
ability to simulate circuits containing them 
thanks

The problem is the fact that oregano allows to use components that
doesn't have models. Then when someone tries to simulate such circuit it
complains that such model doesn't exist. Like a push button(the most
complicated thing in the universe)!

So problem is the fact that oregano advertise that it is capable of
placing a push button, but only to display a nice graphic on the screen.
Either don't show components without models or warn about the fact that
You are unable to simulate circuits containing them.


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



Bug#765622: A patch that might work

2014-11-16 Thread Krzysztof A. Sobiecki
fstab-generator-don-t-rely-on-usr-being-mounted-in-t.patch breaks boot
up on dracut.
As dracut supports usr-mount in initramfs, systemd should be free to
enable it.
So I have made this patch:

--- systemd-215/src/fstab-generator/fstab-generator.c	2014-11-16 18:20:59.566309234 +0100
+++ systemd-215-new/src/fstab-generator/fstab-generator.c	2014-11-16 18:20:06.606835850 +0100
@@ -159,10 +159,18 @@ static bool mount_is_network(struct mnte
 
 static bool mount_in_initrd(struct mntent *me) {
 assert(me);
+bool dracut = false;
+_cleanup_free_ char *name= NULL;
 
+if (parse_env_file("/etc/initrd-release", NEWLINE, "NAME", &name, NULL) == -ENOENT)
+parse_env_file("/usr/lib/initrd-release", NEWLINE, "NAME", &name, NULL);
+
+if (name && strcmp(name, "dracut") == 0)
+dracut = true;
+
 return
 hasmntopt(me, "x-initrd.mount") ||
-streq(me->mnt_dir, "/usr");
+(streq(me->mnt_dir, "/usr") && dracut);
 }
 
 static int add_mount(

-- 
X was an interactive protocol: 
alpha blending a full-screen image looked like slugs racing down the monitor. 
http://www.keithp.com/~keithp/talks/usenix2000/render.html


Bug#765622: Or not, the solution

2014-11-15 Thread Krzysztof A. Sobiecki
I'm back with dracut and systemd
The problem might lie in fact that systemd-fstab-generator doesn't
generate an entry for /usr while run from initramfs, adding
x-initrd.mount to /usr options(fstab) fixes this bug. I have read that
/usr should be generated without this addition. And it would be, but a
wonderful patch
fstab-generator-don-t-rely-on-usr-being-mounted-in-t.patch in systemd
breaks it. Good job.
-- 
X was an interactive protocol: 
alpha blending a full-screen image looked like slugs racing down the monitor. 
http://www.keithp.com/~keithp/talks/usenix2000/render.html


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



Bug#765622: I'm so glad

2014-10-31 Thread Krzysztof A. Sobiecki
It could be fixed by a simple change to a base-files, but no.
Due to other problems with dracut, I have switched back to initramfs-tools.

-- 
X was an interactive protocol: 
alpha blending a full-screen image looked like slugs racing down the monitor. 
http://www.keithp.com/~keithp/talks/usenix2000/render.html


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



Bug#765622: Dracut, systemd and base-files

2014-10-27 Thread Krzysztof A. Sobiecki
>So, which package is to blame for not booting? dracut or systemd?
Dracut uses Systemd as initial init system. Systemd should switch
to real / using /lib/systemd/system/initrd-switch-root.service

It calls "/bin/systemctl --no-block --force switch-root /sysroot"
During this it checks /sysroot for /etc/os-release.
Because thanks to base-files /etc/os-release is a link to
../usr/lib/os-release it fails on systems with separate /usr.

Applying one of my patches to base-files fixes boot problem with dracut
and systemd. I think that patching systemd to not search for
/etc/os-release would also fix it.

-- 
X was an interactive protocol: 
alpha blending a full-screen image looked like slugs racing down the monitor. 
http://www.keithp.com/~keithp/talks/usenix2000/render.html


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



Bug#758531: Better looking patch

2014-08-20 Thread Krzysztof A. Sobiecki
Felipe Sateler  writes:

> (Why did you not CC the bug? Please CC the bug if not intentional)
>
> On Wed, Aug 20, 2014 at 10:46 AM, Krzysztof A. Sobiecki
>  wrote:
>> Felipe Sateler  writes:
>>
>>> Hi,
>>>
>>> On Wed, Aug 20, 2014 at 8:58 AM, Krzysztof A. Sobiecki  
>>> wrote:
>>>> A better looking patch to disable parallel builds
>>>>
>>>> --- pulseaudio-5.0.orig/src/Makefile.am
>>>> +++ pulseaudio-5.0/src/Makefile.am
>>>> @@ -2195,3 +2195,4 @@ coverage:
>>>>  endif
>>>>
>>>>  .PHONY: massif update-all update-ffmpeg update-map-file coverage
>>>> +.NOTPARALLEL:
>>>
>>> Why disable parallel building?
>>>
>> Because it causes a build failure? I think?
>
> I assume that is the proximate cause. But building in parallel works
> here and in porterboxes, so I thought you could shed some light on
> what is exactly failing.
 To be precise it's install process that fails while parallel make is
used. I think that this causes my problem:
install-modlibexecLTLIBRARIES is run with other targets in install-exec-am
and not all libraries were copied in time to debian/tmp before 
install-modlibexecLTLIBRARIES makes
libtool relink some other libraries.

 The fact that linker sometimes complained only about one library make
it almost clear that it's a race condition. Build process worked because
install-libLTLIBRARIES was faster than install-modlibexecLTLIBRARIES.


To make it less luck based, install-libLTLIBRARIES must be run before
install-modlibexecLTLIBRARIES.

That is why parallel build might fail sometimes.
Also I know nothing about autotools.

>
> In the mean time, please stick with the unstable package. THe one in
> experimental is work in progress.
To miss all the fun?

-- 
X was an interactive protocol: 
alpha blending a full-screen image looked like slugs racing down the monitor. 
http://www.keithp.com/~keithp/talks/usenix2000/render.html


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



Bug#758531: Better looking patch

2014-08-20 Thread Krzysztof A. Sobiecki
A better looking patch to disable parallel builds
--- pulseaudio-5.0.orig/src/Makefile.am
+++ pulseaudio-5.0/src/Makefile.am
@@ -2195,3 +2195,4 @@ coverage:
 endif
 
 .PHONY: massif update-all update-ffmpeg update-map-file coverage
+.NOTPARALLEL:

and a patch to disable tests as memblock-test fails, to lazy to fix
--- pulseaudio-5.0-10/debian/rules	2014-08-17 19:41:11.0 +0200
+++ pulseaudio-5.0/debian/rules	2014-08-20 05:29:51.232507731 +0200
@@ -50,7 +50,7 @@ clean::
 
 # Libs should be in the multi-arch path, but the modules should be in the
 # normal directory as pulseaudio is foreign
-DEB_CONFIGURE_EXTRA_FLAGS = --enable-x11 \
+DEB_CONFIGURE_EXTRA_FLAGS = --enable-x11 --disable-tests \
   --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
   --with-module-dir=\$${prefix}/lib/pulse-$(DEB_UPSTREAM_VERSION)/modules
 

Thanks
-- 
X was an interactive protocol: 
alpha blending a full-screen image looked like slugs racing down the monitor. 
http://www.keithp.com/~keithp/talks/usenix2000/render.html


Bug#758531: Nice patch?

2014-08-19 Thread Krzysztof A. Sobiecki
Dropping patch:
util-Try-finding-out-application-name-using-dladdr.patch
fixes this problem

broken lib have this undefined symbol:
readelf -s libpulse.so.0.17.3  |grep main
   181:  0 NOTYPE  GLOBAL DEFAULT  UND main

good ones lack it

Also I wasn't able to build it without this patch:
Description: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 pulseaudio (5.0-10.1) UNRELEASED; urgency=medium
 .
   * Testing?
Author: root 

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: , 
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: 
Reviewed-By: 
Last-Update: 

--- pulseaudio-5.0.orig/src/Makefile.am
+++ pulseaudio-5.0/src/Makefile.am
@@ -2195,3 +2195,4 @@ coverage:
 endif
 
 .PHONY: massif update-all update-ffmpeg update-map-file coverage
+.NOTPARALLEL:

It is build in the wrong order. Thanks make and/or libtool.
-- 
X was an interactive protocol: 
alpha blending a full-screen image looked like slugs racing down the monitor. 
http://www.keithp.com/~keithp/talks/usenix2000/render.html


Bug#756941: A patch and a bug

2014-08-15 Thread Krzysztof A. Sobiecki
Gnome have already fixed this bug:

https://mail.gnome.org/archives/commits-list/2014-May/msg01007.html
https://bugzilla.gnome.org/show_bug.cgi?id=728449

Patch works.

-- 
X was an interactive protocol: 
alpha blending a full-screen image looked like slugs racing down the monitor. 
http://www.keithp.com/~keithp/talks/usenix2000/render.html


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



Bug#656540: Aw, snap chromium and ssse3

2012-04-15 Thread Krzysztof A. Sobiecki
I have similar problem with Chromium. Sometimes it "Aw, snap" on me
when I tried to watch html5 video.

My problem is caused by illegal instruction, bug is described here:
http://code.google.com/p/chromium/issues/detail?id=107532

Applying media.gyp.patch fixes this issue
--- trunk/src/media/media.gyp	2012/02/04 16:53:31	120484
+++ trunk/src/media/media.gyp	2012/02/04 16:53:39	120485
@@ -467,14 +467,6 @@
 [ 'os_posix == 1 and OS != "mac" and OS != "android"', {
   'cflags': [
 '-msse2',
-'-msse3',
-'-mssse3',
-  ],
-}],
-[ 'OS == "openbsd"', {
-  # OpenBSD's gcc (4.2.1) does not support -mssse3
-  'cflags!': [
-'-mssse3',
   ],
 }],
 [ 'OS == "mac"', {

I'm also including backtrace in case that it's separate bug:

Program received signal SIGILL, Illegal instruction.
media::FilterYUVRows_SSE2 (dest=0x7fff4800 '\020' ..., 
src0=0x5a998000 '\020' ..., 
src1=0x5a9981e0 '\020' ..., width=480, fraction=216)
at media/base/simd/filter_yuv_sse2.cc:33
33  media/base/simd/filter_yuv_sse2.cc: Nie ma takiego pliku ani katalogu.
(gdb) bt
#0  media::FilterYUVRows_SSE2 (
dest=0x7fff4800 '\020' ..., 
src0=0x5a998000 '\020' ..., 
src1=0x5a9981e0 '\020' ..., width=480, fraction=216)
at media/base/simd/filter_yuv_sse2.cc:33
#1  0x58090980 in media::ScaleYUVToRGB32 (
y_buf=0x5a998000 '\020' ..., 
u_buf=0x5a9b7a40 
"\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200"...,
 
v_buf=0x5a9bf8d0 
"\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\2---Type
  to continue, or q  to quit---
00\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200\200"...,
 rgb_buf=0x7fffe381f200 "", source_width=480, 
source_height=270, width=640, height=320, y_pitch=480, uv_pitch=240, 
rgb_pitch=2560, yuv_type=media::YV12, view_rotate=media::ROTATE_0, 
filter=) at media/base/yuv_convert.cc:246
#2  0x5776b643 in webkit_media::FastPaint (video_frame=..., 
canvas=, dest_rect=...)
at webkit/media/skcanvas_video_renderer.cc:188
#3  0x5776bc21 in webkit_media::SkCanvasVideoRenderer::Paint (
this=0x5a848270, video_frame=0x5a114700, canvas=0x5adcd000, 
dest_rect=...) at webkit/media/skcanvas_video_renderer.cc:256
#4  0x57761c41 in webkit_media::WebMediaPlayerProxy::Paint (
this=0x5a848240, canvas=0x5adcd000, dest_rect=...)
at webkit/media/webmediaplayer_proxy.cc:59
#5  0x5775fad2 in webkit_media::WebMediaPlayerImpl::paint (
this=0x5a3353c0, canvas=0x5adcd000, rect=...)
at webkit/media/webmediaplayer_impl.cc:514
#6  0x56a9f744 in paintCurrentFrameInContext (rect=..., 
context=, this=0x5a21b780)
---Type  to continue, or q  to quit---
at 
third_party/WebKit/Source/WebKit/chromium/src/WebMediaPlayerClientImpl.cpp:506
#7  WebKit::WebMediaPlayerClientImpl::paintCurrentFrameInContext (
this=0x5a21b780, context=, rect=...)
at 
third_party/WebKit/Source/WebKit/chromium/src/WebMediaPlayerClientImpl.cpp:494
#8  0x57279a11 in WebCore::RenderVideo::paintReplaced (
this=0x5ad1d810, paintInfo=..., paintOffset=...)
at third_party/WebKit/Source/WebCore/rendering/RenderVideo.cpp:215
#9  0x5724456a in paint (paintOffset=..., paintInfo=..., 
this=0x5ad1d810)
at third_party/WebKit/Source/WebCore/rendering/RenderReplaced.cpp:152
#10 WebCore::RenderReplaced::paint (this=0x5ad1d810, pa

Bug#586807: dash: Dash is unable to execute read only scripts

2010-08-01 Thread Krzysztof A. Sobiecki
Jonathan Nieder  writes:

> Hi Krzysztof,
>
> Sorry for the long delay in responding.
>
> Krzysztof A. Sobiecki wrote:
>
> [...]
>> +++ dash-0.5.6.1/src/input.c 2010-06-25 00:45:19.0 +0200
>> @@ -400,15 +402,28 @@ popstring(void)
>>   */
>>  
>>  int
>> +isdir(const char *name)
>> +{
>> +struct stat64 st;
>> +if (stat64(name, &st) < 0)
>> +return -1;
>> +if (S_ISDIR(st.st_mode)) {
>> +return -1;
>> +}
>> +return 0;
>> +}
>
> This function does not distinguish between failures where errno is set
> and where it is not...
>
>> +
>> +int
>>  setinputfile(const char *fname, int flags)
>>  {
>>  int fd;
>>  
>>  INTOFF;
>> -if ((fd = open(fname, O_RDONLY)) < 0) {
>> +if ((isdir(fname) < 0) || ((fd = open(fname, O_RDONLY)) < 0)) {
>>  if (flags & INPUT_NOFILE_OK)
>>  goto out;
>> -sh_error("Can't open %s", fname);
>> +exitstatus = 127;
>> +exerror(EXIFILE, "Can't open %s", fname);
>
> ... so the caller unconditionally suppresses errno.
When I will have some time, I will think about it.

> The isdir() check happens before the open(), leading to unpleasant
> behavior if a file is replaced by a directory between them.
After 5 minutes, I hacked something to work around this problem(I hope).
I have absolutely no faith about it.

> The patch fixes two issues at once: changing the exit status to 127
> and catching attempts to redirect from a directory.
I have tried to split it in two parts, but I didn't have time to do it
properly. I'm sending what I have.

> That said, do you think this could be made into two patches against
> upstream to be sent to ?
I don't think that this patches are good enough to send them to upstream.
d.diff depends on c.diff

diff -rup ~dash-0.5.6.1/src/error.h tdash-0.5.6.1/src/error.h
--- ~dash-0.5.6.1/src/error.h	2010-08-02 03:05:09.0 +0200
+++ tdash-0.5.6.1/src/error.h	2010-08-02 03:22:21.0 +0200
@@ -69,7 +69,7 @@ extern int exception;
 #define EXSHELLPROC 2	/* execute a shell procedure */
 #define EXEXEC 3	/* command execution failed */
 #define EXEXIT 4	/* exit the shell */
-
+#define EXIFILE 5	/* inputfile cannot be opened or is a directory */
 
 /*
  * These macros allow the user to suspend the handling of interrupt signals
diff -rup ~dash-0.5.6.1/src/options.c tdash-0.5.6.1/src/options.c
--- ~dash-0.5.6.1/src/options.c	2010-08-02 03:05:09.0 +0200
+++ tdash-0.5.6.1/src/options.c	2010-08-02 03:26:06.0 +0200
@@ -35,6 +35,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include "shell.h"
 #define DEFINE_OPTIONS
@@ -117,6 +120,23 @@ STATIC int getopts(char *, char *, char
  */
 
 int
+isdir(const char *name)
+{
+	int fd;
+	struct stat64 st;
+	
+	if ((fd = open(name, O_RDONLY))<0)
+		return -1;
+	if (fstat64(fd, &st) < 0)
+		return -1;
+	if (S_ISDIR(st.st_mode)) {
+		return -1;
+		errno = EISDIR;
+	}
+		return 0;
+}
+
+int
 procargs(int argc, char **argv)
 {
 	int i;
@@ -156,10 +176,16 @@ procargs(int argc, char **argv)
 		if (*xargv)
 			goto setarg0;
 	} else if (!sflag) {
-		setinputfile(*xargv, 0);
+		if(!isdir(*xargv)) {
+			setinputfile(*xargv, 0);
+		}
+		else {
+			exerror(EXIFILE, "Can't open %s", *xargv);
+		}
 setarg0:
-		arg0 = *xargv++;
-		commandname = arg0;
+	arg0 = *xargv++;
+	commandname = arg0;
+	
 	}
 
 	shellparam.p = xargv;
diff -rup tdash-0.5.6.1/src/options.c dash-0.5.6.1/src/options.c
--- tdash-0.5.6.1/src/options.c	2010-08-02 03:26:06.0 +0200
+++ dash-0.5.6.1/src/options.c	2010-08-02 03:26:31.0 +0200
@@ -180,6 +180,7 @@ procargs(int argc, char **argv)
 			setinputfile(*xargv, 0);
 		}
 		else {
+			exitstatus = 127;
 			exerror(EXIFILE, "Can't open %s", *xargv);
 		}
 setarg0:


-- 
X was an interactive protocol: 
alpha blending a full-screen image looked like slugs racing down the monitor. 
http://www.keithp.com/~keithp/talks/usenix2000/render.html


Bug#586807: Patch

2010-06-24 Thread Krzysztof A. Sobiecki

This how I think fixed patch should look like.
It's only quick hack but for now it's best thing I have.

diff -rup ~dash-0.5.6.1/src/error.h dash-0.5.6.1/src/error.h
--- ~dash-0.5.6.1/src/error.h	2010-06-24 23:53:42.0 +0200
+++ dash-0.5.6.1/src/error.h	2010-06-24 23:50:58.0 +0200
@@ -69,6 +69,7 @@ extern int exception;
 #define EXSHELLPROC 2	/* execute a shell procedure */
 #define EXEXEC 3	/* command execution failed */
 #define EXEXIT 4	/* exit the shell */
+#define EXIFILE 5	/* inputfile cannot be opened or is a directory */
 
 
 /*
diff -rup ~dash-0.5.6.1/src/input.c dash-0.5.6.1/src/input.c
--- ~dash-0.5.6.1/src/input.c	2010-06-24 23:53:42.0 +0200
+++ dash-0.5.6.1/src/input.c	2010-06-25 00:45:19.0 +0200
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * This file implements the input routines used by the parser.
@@ -54,6 +55,7 @@
 #include "parser.h"
 #include "main.h"
 #include "var.h"
+#include "eval.h"
 #ifndef SMALL
 #include "myhistedit.h"
 #endif
@@ -400,15 +402,28 @@ popstring(void)
  */
 
 int
+isdir(const char *name)
+{
+	struct stat64 st;
+	if (stat64(name, &st) < 0)
+		return -1;
+	if (S_ISDIR(st.st_mode)) {
+		return -1;
+	}
+	return 0;
+}
+
+int
 setinputfile(const char *fname, int flags)
 {
 	int fd;
 
 	INTOFF;
-	if ((fd = open(fname, O_RDONLY)) < 0) {
+	if ((isdir(fname) < 0) || ((fd = open(fname, O_RDONLY)) < 0)) {
 		if (flags & INPUT_NOFILE_OK)
 			goto out;
-		sh_error("Can't open %s", fname);
+		exitstatus = 127;
+		exerror(EXIFILE, "Can't open %s", fname);
 	}
 	if (fd < 10)
 		fd = savefd(fd, fd);

-- 
X was an interactive protocol: 
alpha blending a full-screen image looked like slugs racing down the monitor. 
http://www.keithp.com/~keithp/talks/usenix2000/render.html


Bug#586807: dash: Dash is unable to execute read only scripts

2010-06-22 Thread Krzysztof A. Sobiecki
Package: dash
Version: 0.5.6.1-1~exp0
Severity: critical

When user doesn't have write access to script :
sob...@solis:/tmp$ ls -lh ./a.sh 
-r-xr-x--- 1 sobkas sobkas 9 06-22 19:20 ./a.sh

dash fails to start it with this error(I have dash as sh)

sob...@solis:/tmp$ ./a.sh 
/bin/sh: Can't open ./a.sh

During the boot-up process / partition is read-only and because of that
dash is unable to execute /etc/init.d/rcS and /etc/init.d/rc scripts.

Apparently problem lies inside patch:
 0006--INPUT-exit-127-if-command_file-is-given-but-doesn-t.diff
Why would anyone want to open script in read-write mode?

-   if ((fd = open(fname, O_RDONLY)) < 0) {
+   if ((fd = open(fname, O_RDWR)) < 0) {

After changing it back to O_RDONLY dash properly executes read-only scripts.


-- System Information:
Debian Release: squeeze/sid
  APT prefers experimental
  APT policy: (501, 'experimental'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.34-rc5-00159-g5997e26-dirty (SMP w/2 CPU cores)
Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dash depends on:
ii  debianutils   3.2.3  Miscellaneous utilities specific t
ii  dpkg  1.15.7.2   Debian package management system
ii  libc6 2.11.1-3   Embedded GNU C Library: Shared lib

dash recommends no packages.

dash suggests no packages.

-- debconf-show failed

-- 
X was an interactive protocol: 
alpha blending a full-screen image looked like slugs racing down the monitor. 
http://www.keithp.com/~keithp/talks/usenix2000/render.html



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



Bug#557392: libsoup2.4-1: Bug inside libsoup2.4-1 causes liferea(1.6.0-1+b1) to crash.

2009-11-21 Thread Krzysztof A. Sobiecki
Package: libsoup2.4-1
Version: 2.28.1-3
Severity: important
Tags: patch

Liferea crashes inside libsoup library. 
Functions that causes this problem are apparently called in this order:
dispose -> stop_idle_timer -> g_source_destroy
I think that sometimes g_source_destroy destroys source already
destroyed. To prevent this, I have made a small patch. It might be
useful, but I can't assure that it's correct. It's based on git
repository, but it applies cleanly on libsoup 2.28.1-3.

-- System Information:
Debian Release: squeeze/sid
  APT prefers experimental
  APT policy: (501, 'experimental'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.31-rc9 (SMP w/2 CPU cores)
Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libsoup2.4-1 depends on:
ii  libc6   2.10.1-7 GNU C Library: Shared libraries
ii  libgcrypt11 1.4.4-5  LGPL Crypto library - runtime libr
ii  libglib2.0-02.22.2-2 The GLib library of C routines
ii  libgnutls26 2.8.5-2  the GNU TLS library - runtime libr
ii  libxml2 2.7.6.dfsg-1 GNOME XML library

libsoup2.4-1 recommends no packages.

libsoup2.4-1 suggests no packages.

-- no debconf information

(gdb) bt full
#0  __pthread_mutex_lock (mutex=0x732f2f3a70747470) at pthread_mutex_lock.c:50
__PRETTY_FUNCTION__ = "__pthread_mutex_lock"
type = 
#1  0x7fe96cd72e36 in g_source_destroy_internal (source=0x42914b0, 
context=0x732f2f3a70747468, have_lock=0)
at /tmp/buildd/glib2.0-2.22.2/glib/gmain.c:837
No locals.
#2  0x7fe96f36496a in stop_idle_timer (object=0x4127800) at 
soup-connection.c:307
No locals.
#3  dispose (object=0x4127800) at soup-connection.c:113
conn = 0x4127800
priv = 
#4  0x7fe96d00c332 in IA__g_object_unref (_object=) at 
/tmp/buildd/glib2.0-2.22.2/gobject/gobject.c:2441
object = 0x4127800
old_ref = 
__PRETTY_FUNCTION__ = "IA__g_object_unref"
#5  0x7fe96f379987 in message_finished (msg=0x40d8040, user_data=) at soup-session.c:1234
item = 0x4142a40
session = 0x20ab8e0
host = 
#6  0x7fe96d00a3ed in IA__g_closure_invoke (closure=0x41b97b0, 
return_value=0x0, n_param_values=1, param_values=0x4134d60, 
invocation_hint=0x7fffd0e37410) at 
/tmp/buildd/glib2.0-2.22.2/gobject/gclosure.c:767
marshal = 0x41bb60 
marshal_data = 0x0
__PRETTY_FUNCTION__ = "IA__g_closure_invoke"
#7  0x7fe96d01e24c in signal_emit_unlocked_R (node=0x24f4f00, detail=0, 
instance=0x40d8040, emission_return=0x0, 
instance_and_params=0x4134d60) at 
/tmp/buildd/glib2.0-2.22.2/gobject/gsignal.c:3317
tmp = 
handler = 0x4076290
accumulator = 0x0
emission = {next = 0x0, instance = 0x40d8040, ihint = {signal_id = 348, 
detail = 0, run_type = G_SIGNAL_RUN_LAST}, state = EMISSION_RUN, 
  chain_type = 4}
class_closure = 0x2577cf0
handler_list = 0x4076290
return_accu = 0x0
accu = {g_type = 0, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong 
= 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, 
  v_pointer = 0x0}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 
0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, 
  v_pointer = 0x0}}}
signal_id = 348
max_sequential_handler_number = 16851
return_value_altered = 1
#8  0x7fe96d01f082 in IA__g_signal_emit_valist (instance=0x40d8040, 
signal_id=, detail=0, var_args=0x7fffd0e375f0)
at /tmp/buildd/glib2.0-2.22.2/gobject/gsignal.c:2980
signal_return_type = 4
param_values = 0x4134d78
node = 0x24f4f00
i = 0
n_params = 0
__PRETTY_FUNCTION__ = "IA__g_signal_emit_valist"
#9  0x7fe96d01f553 in IA__g_signal_emit (instance=0x732f2f3a70747470, 
signal_id=1886680168, detail=0)
at /tmp/buildd/glib2.0-2.22.2/gobject/gsignal.c:3037
var_args = {{gp_offset = 24, fp_offset = 48, overflow_arg_area = 
0x7fffd0e376d0, reg_save_area = 0x7fffd0e37610}}
#10 0x7fe96f379bf5 in soup_session_connection_failed (session=0x20ab8e0, 
conn=, status=4) at soup-session.c:1045
priv = 0x20ab900
host = 0x4133660
item = 
msg = 0x40d8040
#11 0x7fe96f37b863 in got_connection (conn=0x40ee030, status=, session=0x20ab8e0) at soup-session-async.c:290
tunnel_addr = 
#12 0x7fe96f36481c in socket_connect_result (sock=0x7fe95004c240, status=4, 
user_data=) at soup-connection.c:389
data = 0x4465e60
priv = 0x40ee050
#13 0x7fe96f37e590 in idle_connect_result (user_data=) 
at soup-socket.c:588
sacd = 0x40da290
priv = 0x7fe95004c260
status = 1886680168
#14 0x7fe96f37e747 in connect_watch (iochannel=, 
condition=24, data=) at soup-socket.c:615
sacd = 0x40da290
priv = 
error = 0

Bug#551570: oh my

2009-10-23 Thread Krzysztof A. Sobiecki
Some later changes complicated everything.
After 33be73dfb76c26e3bb0ab59b2f570d00d9c7be62 I don't see anything
strange. I don't know.
I must think a bit about it.
-- 
X was an interactive protocol: 
alpha blending a full-screen image looked like slugs racing down the monitor. 
http://www.keithp.com/~keithp/talks/usenix2000/render.html



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



Bug#551570: Quick bisect

2009-10-23 Thread Krzysztof A. Sobiecki
After a quick bisect I have found that problem lies in commit:
40aefac5d714bf7536632ed38c7a8ee05049f30b inside cairo.
In bug 551852(with might be a duplicate of this one) I have included
backtrace. 

This commit, doesn't even make any difference, with python test case
included in:
https://bugs.freedesktop.org/show_bug.cgi?id=12996, so I don't really
see any point in it.


-- 
X was an interactive protocol: 
alpha blending a full-screen image looked like slugs racing down the monitor. 
http://www.keithp.com/~keithp/talks/usenix2000/render.html



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



Bug#551852: Maybe it's a libcario2 problem?

2009-10-22 Thread Krzysztof A. Sobiecki
I have same(I hope) problem with iceweasel's crashes. After closing of 
several tabs, browser crashes. 

After some testing, I think it might be connected with libcario2 
1.9.4-1 from experimental. Downgrading libcario2 to version from
unstable(1.8.8-2) fixed(?) problem. 

Testing will be appreciated.

Output from gdb is attached. Iceweasel was started with --sync option.


(gdb) b gdk_x_error
Breakpoint 1 at 0x7ff0b7f544d0: file 
/tmp/buildd/gtk+2.0-2.18.3/gdk/x11/gdkmain-x11.c, line 438.
Current language:  auto
The current source language is "auto; currently c".
(gdb) c
Continuing.
[Thread 0x7ff09dfff910 (LWP 2991) exited]
[New Thread 0x7ff09dfff910 (LWP 7151)]
[Thread 0x7ff09dfff910 (LWP 7151) exited]
[Thread 0x7ff09efff910 (LWP 2986) exited]
[Thread 0x7ff0996ff910 (LWP 2994) exited]
[Thread 0x7ff09a2ff910 (LWP 2995) exited]
[Thread 0x7ff09aeff910 (LWP 2992) exited]
[Thread 0x7ff09fdf8910 (LWP 2985) exited]
[Thread 0x7ff0989ff910 (LWP 2996) exited]
[New Thread 0x7ff0989ff910 (LWP 8285)]
[New Thread 0x7ff09fdf8910 (LWP 8286)]

Breakpoint 1, gdk_x_error (display=0x7ff0bd5b, error=0x7fffd6caf550) at 
/tmp/buildd/gtk+2.0-2.18.3/gdk/x11/gdkmain-x11.c:438
438 /tmp/buildd/gtk+2.0-2.18.3/gdk/x11/gdkmain-x11.c: Nie ma takiego pliku 
ani katalogu.
in /tmp/buildd/gtk+2.0-2.18.3/gdk/x11/gdkmain-x11.c
(gdb) bt
#0  gdk_x_error (display=0x7ff0bd5b, error=0x7fffd6caf550) at 
/tmp/buildd/gtk+2.0-2.18.3/gdk/x11/gdkmain-x11.c:438
#1  0x7ff0ba06a98c in _XError (dpy=0x7ff0bd5b, rep=0x7ff0885c1f70) at 
XlibInt.c:3103
#2  0x7ff0ba071a14 in process_responses (dpy=0x7ff0bd5b, 
wait_for_first_event=0, current_error=0x7fffd6caf6a8, current_request=2451320) 
at xcb_io.c:214
#3  0x7ff0ba0720f0 in _XReply (dpy=0x7ff0bd5b, rep=0x7fffd6caf6f0, 
extra=0, discard=1) at xcb_io.c:464
#4  0x7ff0ba066183 in XSync (dpy=0x7ff0bd5b, discard=0) at Sync.c:48
#5  0x7ff0ba06633b in _XSyncFunction (dpy=0x7ff0bd5b) at Synchro.c:37
#6  0x7ff0baa7c18c in _cairo_xlib_surface_finish (abstract_surface=) at /tmp/buildd/cairo-1.9.4/src/cairo-xlib-surface.c:402
#7  0x7ff0baa5ac57 in *INT_cairo_surface_finish (surface=0x7ff08a96bc00) at 
/tmp/buildd/cairo-1.9.4/src/cairo-surface.c:652
#8  0x7ff0baa5acf5 in *INT_cairo_surface_destroy (surface=0x7ff0bd5b) 
at /tmp/buildd/cairo-1.9.4/src/cairo-surface.c:584
#9  0x7ff0bcc4b7a1 in gfxASurface::Release (this=0x7ff0892d2bc0) at 
gfxASurface.cpp:104
#10 0x7ff0bcb673a7 in nsRefPtr::assign_assuming_AddRef 
(this=0x7ff0891eff10, rhs=0x0) at ../../../dist/include/xpcom/nsAutoPtr.h:944
#11 nsRefPtr::assign_with_AddRef (this=0x7ff0891eff10, rhs=0x0) at 
../../../dist/include/xpcom/nsAutoPtr.h:928
#12 nsRefPtr::operator= (this=0x7ff0891eff10, rhs=0x0) at 
../../../dist/include/xpcom/nsAutoPtr.h:1003
#13 0x7ff0bcb64406 in nsWindow::Destroy (this=0x7ff0891efe00) at 
nsWindow.cpp:787
#14 0x7ff0bc81a857 in ~nsView (this=0x7ff0881d4b00, __in_chrg=) at nsView.cpp:272
#15 0x7ff0bc5f4bec in nsFrame::Destroy (this=0x7ff0885aeae0) at 
nsFrame.cpp:535
#16 0x7ff0bc5ea645 in nsContainerFrame::Destroy (this=0x7ff0885aeae0) at 
nsContainerFrame.cpp:305
#17 0x7ff0bc5bfe08 in nsFrameManager::Destroy (this=0x7ff08ccdf838) at 
nsFrameManager.cpp:292
#18 0x7ff0bc5d3c8e in PresShell::Destroy (this=0x7ff08ccdf800) at 
nsPresShell.cpp:1949
#19 0x7ff0bc5b8837 in DocumentViewerImpl::DestroyPresShell 
(this=0x7ff0892f6340) at nsDocumentViewer.cpp:4260
#20 0x7ff0bc5bc3d5 in DocumentViewerImpl::Destroy (this=0x7ff0892f6340) at 
nsDocumentViewer.cpp:1534
#21 0x7ff0bca11c34 in nsSHistory::EvictContentViewersInRange (this=, aStart=4, aEnd=8) at nsSHistory.cpp:881
#22 0x7ff0bca11cf6 in nsSHistory::EvictAllContentViewers 
(this=0x7ff0bd5b) at nsSHistory.cpp:672
#23 0x7ff0bc9eb63f in nsDocShell::Destroy (this=0x7ff0881c1000) at 
nsDocShell.cpp:3950
#24 0x7ff0bc708360 in nsFrameLoader::Finalize (this=0x7ff0895339d0) at 
nsFrameLoader.cpp:291
#25 0x7ff0bc6fa58f in nsDocument::MaybeInitializeFinalizeFrameLoaders 
(this=) at nsDocument.cpp:5277
#26 0x7ff0bc6fc953 in nsDocument::EndUpdate (this=0x7ff09f472000, 
aUpdateType=1) at nsDocument.cpp:3758
#27 0x7ff0bc811ff5 in nsXULDocument::EndUpdate (this=0x7ff0bd5b, 
aUpdateType=3603625296) at nsXULDocument.cpp:3358
#28 0x7ff0bc66bb2e in ~mozAutoDocUpdate (this=0x7fffd6cafc20, 
__in_chrg=) at 
./../../content/base/src/mozAutoDocUpdate.h:66
#29 0x7ff0bc71178e in nsGenericElement::doRemoveChildAt (aIndex=0, 
aNotify=1, aKid=0x7ff0881f0790, aParent=, 
aDocument=0x7ff09f472000, 
aChildArray=...) at nsGenericElement.cpp:3380
#30 0x7ff0bc711907 in nsGenericElement::RemoveChildAt (this=0x7ff09e445290, 
aIndex=0, aNotify=1) at nsGenericElement.cpp:3305
#31 0x7ff0bc8ef180 in nsXULElement::RemoveChildAt (this=0x7ff09e445290, 
aIndex=0, aNotify=1) at nsXULElement.cpp:962
#32 0x7ff0bc70e292 in nsGenericElement::doRemoveChild 
(aOldChild=0x7ff0881f07c8, a

Bug#529865: Uh, oh

2009-05-24 Thread Krzysztof A. Sobiecki
In the previous patch there is big problem in handling 0 as button
number(-u). It still sets buttons even if there is no proper axmap. This patch 
fixes
this. It also eliminates one global variable. 
diff -rup ~joystick-20051019/utils/jscal.c joystick-20051019/utils/jscal.c
--- ~joystick-20051019/utils/jscal.c	2009-05-19 12:07:27.0 +0200
+++ joystick-20051019/utils/jscal.c	2009-05-24 21:16:48.0 +0200
@@ -62,6 +62,7 @@ struct correction_data {
 int fd;
 struct js_corr corr[MAX_AXES];
 __u8 axmap[ABS_MAX + 1];
+__u8 axmap2[ABS_MAX + 1];
 __u16 buttonmap[(KEY_MAX - BTN_MISC + 1)];
 char axes, buttons, fuzz;
 int version;
@@ -354,8 +355,7 @@ void print_mappings(char *devicename)
 		exit(1);
 	}
 	if (ioctl(fd, JSIOCGBTNMAP, &buttonmap)) {
-		perror("jscal: error getting button map");
-		exit(1);
+	buttons=0;
 	}
 
 	printf("jscal -u %d", axes);
@@ -373,6 +373,44 @@ void print_mappings(char *devicename)
 	printf(" %s\n",devicename);
 }
 
+
+void get_axmap2(void)
+{
+if (ioctl(fd, JSIOCGAXMAP, &axmap2)) {
+		perror("jscal: error getting axis map");
+		exit(1);
+	}
+}
+
+void correct_axes(void)
+{
+int axmes[ABS_MAX + 1];
+struct js_corr corr_tmp[MAX_AXES];
+int i;
+int ax[axes];
+	//Create remapping table
+for(i=0;i

Bug#529865: joystick: Patch adding new functionality to -u and -q options

2009-05-21 Thread Krzysztof A. Sobiecki
Package: joystick
Version: 20051019-5
Severity: wishlist
Tags: patch

Patch adds new functionality to -u and -q options of joystick.
Remapping axes (-u) will also move their calibration settings with
them. It also add option to ignore buttons while touching only
axes. Something like this:
jscal -u 4,0,1,2,3,0 /dev/input/js0
0 instead of real buttons number will make jscal ignore them.

Changes in printing current mappings (-q) are somewhat more problematic.
jscal -q /dev/input/js0 will act the same unless it encounter bug in
JSIOCGBTNMAP in this case I set number of buttons to 0 and print
something like that:
jscal -u 4,0,1,2,3,0 /dev/input/js0
Changing axes mappings still work and buttons can be ignored.

Patch is still rough a bit, but I can change it according to feedback.

diff -rup ~joystick-20051019/utils/jscal.c joystick-20051019/utils/jscal.c
--- ~joystick-20051019/utils/jscal.c	2009-05-19 12:07:27.0 +0200
+++ joystick-20051019/utils/jscal.c	2009-05-21 12:54:32.0 +0200
@@ -61,7 +61,9 @@ struct correction_data {
 
 int fd;
 struct js_corr corr[MAX_AXES];
+struct js_corr corr2[MAX_AXES];
 __u8 axmap[ABS_MAX + 1];
+__u8 axmap2[ABS_MAX + 1];
 __u16 buttonmap[(KEY_MAX - BTN_MISC + 1)];
 char axes, buttons, fuzz;
 int version;
@@ -354,8 +356,7 @@ void print_mappings(char *devicename)
 		exit(1);
 	}
 	if (ioctl(fd, JSIOCGBTNMAP, &buttonmap)) {
-		perror("jscal: error getting button map");
-		exit(1);
+	buttons=0;
 	}
 
 	printf("jscal -u %d", axes);
@@ -373,6 +374,45 @@ void print_mappings(char *devicename)
 	printf(" %s\n",devicename);
 }
 
+
+void get_axmap2(void)
+{
+if (ioctl(fd, JSIOCGAXMAP, &axmap2)) {
+		perror("jscal: error getting axis map");
+		exit(1);
+	}
+}
+
+void correct_axes(void)
+{
+int axmes[ABS_MAX + 1];
+int i;
+int ax[axes];
+for(i=0;i

Bug#498682: I hate tray-icons

2009-02-19 Thread Krzysztof A. Sobiecki
Tags: patch
Something strange happening with tray-icon in miro. For now good option
is to disable it. I don't have time to fight with it right now, maybe later.
I hope this will help:
diff -rup ~miro-2.0.1/portable/frontends/widgets/gtk/trayicon.py miro-2.0.1/portable/frontends/widgets/gtk/trayicon.py
--- ~miro-2.0.1/portable/frontends/widgets/gtk/trayicon.py	2009-02-11 22:37:21.0 +0100
+++ miro-2.0.1/portable/frontends/widgets/gtk/trayicon.py	2009-02-20 02:23:08.0 +0100
@@ -44,7 +44,7 @@ trayicon_is_supported = False
 # trayicons (the GtkStatusIcon widget).  Specifically we are looking
 # for GTK+ version 2.10 or newer.
 if gtk.check_version(2, 10, 0) == None:
-trayicon_is_supported = True
+trayicon_is_supported = False
 
 class Trayicon(gtk.StatusIcon):
 def __init__(self, icon):
0x7f5e5209e1f4 in __lll_lock_wait () from /lib/libpthread.so.0
(gdb) bt
#0  0x7f5e5209e1f4 in __lll_lock_wait () from /lib/libpthread.so.0
#1  0x7f5e5209c150 in pthread_cond_broadcast@@GLIBC_2.3.2 () from 
/lib/libpthread.so.0
#2  0x7f5e4bd29217 in wait_or_poll_for_event (dpy=0x1486fb0, wait=) at 
../../src/xcb_io.c:141
#3  0x7f5e4bd2958d in process_responses (dpy=0x147c280, 
wait_for_first_event=1, current_error=0x0, 
current_request=0)
at ../../src/xcb_io.c:166
#4  0x7f5e4bd29e49 in _XReadEvents (dpy=0x1486fb0) at ../../src/xcb_io.c:272
#5  0x7f5e4bd08a14 in XIfEvent (dpy=0x1486fb0, event=0x7fff5a4c3e70, 
predicate=0x7f5e423aa410 
, 
arg=0x2800115 "ngs/toolbar.xml#toolbarpaletteitem") at 
../../src/IfEvent.c:70
#6  0x7f5e423aa3c7 in IA__gdk_x11_get_server_time (window=)
at /tmp/buildd/gtk+2.0-2.14.7/gdk/x11/gdkevents-x11.c:2600
#7  0x7f5e428a821e in gtk_tray_icon_send_manager_message (icon=0x1a541b0, 
message=128, window=21480128, 
data1=41943317, 
data2=21527048, data3=0) at 
/tmp/buildd/gtk+2.0-2.14.7/gtk/gtktrayicon-x11.c:309
#8  0x7f5e428a8bf0 in gtk_tray_icon_update_manager_window (icon=0x1a541b0)
at /tmp/buildd/gtk+2.0-2.14.7/gtk/gtktrayicon-x11.c:331
#9  0x7f5e428a8e05 in gtk_tray_icon_realize (widget=0x1a541b0) at 
/tmp/buildd/gtk+2.0-2.14.7/gtk/gtktrayicon-x11.c:466
#10 0x7f5e4884c11d in IA__g_closure_invoke (closure=0x1588360, 
return_value=0x0, n_param_values=1, param_values=
0x28ed400, invocation_hint=0x7fff5a4c42a0) at 
/build/buildd/glib2.0-2.18.4/gobject/gclosure.c:767
#11 0x7f5e4885f628 in signal_emit_unlocked_R (node=0x1588df0, detail=0, 
instance=0x1a541b0, emission_return=0x0, 
instance_and_params=0x28ed400) at 
/build/buildd/glib2.0-2.18.4/gobject/gsignal.c:3174
#12 0x7f5e488611d8 in IA__g_signal_emit_valist (instance=0x1a541b0, 
signal_id=, detail=0, 
var_args=
0x7fff5a4c4480) at /build/buildd/glib2.0-2.18.4/gobject/gsignal.c:2977
#13 0x7f5e488616d3 in IA__g_signal_emit (instance=0x147c280, signal_id=128, 
detail=21480128)
at /build/buildd/glib2.0-2.18.4/gobject/gsignal.c:3034
#14 0x7f5e4283ab06 in IA__gtk_widget_realize (widget=0x1a541b0) at 
/tmp/buildd/gtk+2.0-2.14.7/gtk/gtkwidget.c:3319
#15 0x7f5e4284ad88 in gtk_window_show (widget=0x1a541b0) at 
/tmp/buildd/gtk+2.0-2.14.7/gtk/gtkwindow.c:4314
#16 0x7f5e4884c11d in IA__g_closure_invoke (closure=0x151fc80, 
return_value=0x0, n_param_values=1, param_values=
0x26a0580, invocation_hint=0x7fff5a4c4740) at 
/build/buildd/glib2.0-2.18.4/gobject/gclosure.c:767
#17 0x7f5e4885f628 in signal_emit_unlocked_R (node=0x1588290, detail=0, 
instance=0x1a541b0, emission_return=0x0, 
instance_and_params=0x26a0580) at 
/build/buildd/glib2.0-2.18.4/gobject/gsignal.c:3174
#18 0x7f5e488611d8 in IA__g_signal_emit_valist (instance=0x1a541b0, 
signal_id=, detail=0, 
var_args=
0x7fff5a4c4920) at /build/buildd/glib2.0-2.18.4/gobject/gsignal.c:2977
#19 0x7f5e488616d3 in IA__g_signal_emit (instance=0x147c280, signal_id=128, 
detail=21480128)
at /build/buildd/glib2.0-2.18.4/gobject/gsignal.c:3034
#20 0x7f5e4283bacc in IA__gtk_widget_show (widget=0x1a541b0) at 
/tmp/buildd/gtk+2.0-2.14.7/gtk/gtkwidget.c:3003
#21 0x7f5e427975a0 in gtk_status_icon_constructor (type=, 
n_construct_properties=, construct_params=)
at /tmp/buildd/gtk+2.0-2.14.7/gtk/gtkstatusicon.c:653
#22 0x7f5e48851ad3 in IA__g_object_newv (object_type=20181888, 
n_parameters=, 
parameters=0x0)
at /build/buildd/glib2.0-2.18.4/gobject/gobject.c:1211
#23 0x7f5e47dda7f8 in ?? () from 
/usr/lib/pymodules/python2.5/gtk-2.0/gobject/_gobject.so
#24 0x7f5e42c8f7f7 in ?? () from 
/usr/lib/pymodules/python2.5/gtk-2.0/gtk/_gtk.so
---Type  to continue, or q  to quit---
#25 0x0045df5c in wrap_init (self=0x147c280, args=0x80, 
wrapped=0xfe00, kwds=0x)
at ../Objects/typeobject.c:4043
#26 0x00418843 in PyObject_Call (func=0x147c280, arg=0x80, 
kw=0x147c2c0) at ../Objects/abstract.c:1861
#27 0x0048b2d2 in PyEval_CallObjectWithKeywords (func=0x2147710, 
arg=0x7f5e52453050, kw=0x0)
   

Bug#488637: Patch that fixes bug for me

2008-07-13 Thread Krzysztof A. Sobiecki
This is small hack that fixes this bug. I hope it wont introduce new ones.

diff -rup ./xine-plugin-1.0.1~cvs20070523/src/npentry.c ~xine-plugin-1.0.1~cvs20070523/src/npentry.c
--- ./xine-plugin-1.0.1~cvs20070523/src/npentry.c	2007-01-18 17:42:55.0 +0100
+++ ~xine-plugin-1.0.1~cvs20070523/src/npentry.c	2008-07-13 14:37:57.0 +0200
@@ -114,7 +114,9 @@ NPError NPN_DestroyStream (NPP instance,
 void NPN_Status (NPP instance, const char* message)
 {
   /* Browsers different from Firefox might not be thread-safe. */
-  if (strstr (NPN_UserAgent(instance), "Firefox"))
+  /* Hack to fix #488637
+   *if (strstr (NPN_UserAgent(instance), "Firefox"))
+   */
 CallNPN_StatusProc (NPNFuncs.status, instance, message);
 }