Bug#589855: p54pci doesn't work with ISL3890 based card

[Jan Capek]

Hi,

yes, I still have the card, I will give it a try.

Jan

Dne Sun, 20 May 2012 01:52:50 -0500
Jonathan Nieder  napsal(a):

> Hi again,
> 
> In November, Jonathan Nieder wrote:
> > Jan Capek wrote:
> 
> >> This card worked with the original prism54 driver. The p54pci
> >> driver causes problems.
> > [...]
> >> I will try to test it with 2.6.38 from squeeze backports. I am
> >> sorry I didn't see the original message from Geoff..
> >
> > No problem.
> 
> Ping.  Do you still have this card?  Did you find out how it works
> with 3.x.y kernels?
> 
> In suspense,
> Jonathan



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

Bug#640982: support for a postexport action in git-buildpackage - helps generating multiple packages from 1 Debian branch

[Jan Capek]

Package: git-buildpackage
Version: 0.5.11
Severity: wishlist
Tags: patch upstream

Hi,

I have decided to use git-buildpackage to build complete cross
toolchain for baremetal systems. In the sequence of building bootstrap
gcc, newlib, and finally full gcc, I have realized I would like to
have just one Debian branch for the gcc and be able to generate either
bootstrap or full gcc. The feature that I was missing in
git-buildpackage was a 'postexport' action that would allow processing
some of the Debian file templates. The attached patch extends
git-buildpackage with this new feature. Please, let me know, if you
have any questions.

Best regards,

Jan Capek

-- System Information:
Debian Release: squeeze/sid
  APT prefers stable
  APT policy: (700, 'stable'), (650, 'testing'), (500, 'oldstable'), (500, 
'stable')
Architecture: amd64 (x86_64)

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

Versions of packages git-buildpackage depends on:
ii  devscripts   2.10.69 scripts to make the life of a Debi
ii  git [git-core]   1:1.7.2.5-1 fast, scalable, distributed revisi
ii  python   2.6.6-14interactive high-level object-orie
ii  python-dateutil  1.4.1-3 powerful extensions to the standar
ii  python-support   1.0.13  automated rebuilding support for P

Versions of packages git-buildpackage recommends:
ii  cowbuilder0.62+nmu2  pbuilder running on cowdancer
ii  pristine-tar  1.00   regenerate pristine tarballs

Versions of packages git-buildpackage suggests:
pn  git-load-dirs  (no description available)

-- 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#589855: linux-image-2.6.32-bpo.5-amd64: p54pci doesn't work with ISL3890 based card

[Jan Capek]

Hi Jonathan,

I will try to test it with 2.6.38 from squeeze backports. I am sorry I
didn't see the original message from Geoff..

Regards,

Jan

 On Tue, 9 Aug 2011 19:01:06 -0500
Jonathan Nieder  wrote:

> Hi Jan,
> 
> Geoff Simmons wrote:
> > On Wed, Jul 21, 2010 at 07:14:01PM +0200, Jan Čapek wrote:
> 
> >> This card worked with the original prism54 driver. The p54pci
> >> driver causes problems.
> > [...]
> >> 03:00.0 Network controller [0280]: Intersil Corporation ISL3890
> >> [Prism GT/Prism Duette]/ISL3886 [Prism Javelin/Prism Xbow]
> >> [1260:3890] (rev 01) Subsystem: Standard Microsystems Corp [SMC]
> >> SMC2802W Wireless PCI Adapter [10b8:2802]
> >
> > According to [1], your device (part number 99-012084-164 is
> > subsystem ID 10b8:2802) is supported by p54pci in Linux 2.6.34.1.
> >
> > Try a test with the 2.6.35-rc6-amd64 kernel package available from
> > experimental, together with the firmware from [2].
> 
> So now I'm in suspense.  Did a later kernel help?
> 
> In v2.6.36-rc1 the appropriate PCI id was added.
> 
> Curious,
> Jonathan
> 
> > [1]
> > http://article.gmane.org/gmane.linux.kernel.wireless.general/53978
> > [2] http://daemonizer.de/prism54/prism54-fw/fw-softmac/2.13.12.0.arm




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

Bug#582075: syncevolution: --configure option doesn't seem to create configuration files

[Jan Capek]

See below
On Tue, 18 May 2010 06:30:45 -0300
David Bremner  wrote:

> On Tue, 18 May 2010 09:07:44 +0200, Jan Čapek 
> wrote:
> > 
> > $ syncevolution --configure --sync-property 'username=123456'
> > --sync-property 'password=1234' scheduleworld
> > 
> > results in virtually nothing, no output, no configuration gets
> > created. 
> 
> This command (with different numbers) works for me here, running
> squeeze on amd64.
> 
> > ii  libebook1.2-9  2.28.3.1-1Client library for
> > evolution addre ii  libecal1.2-7   2.30.1-3  Client
> > library for evolution calen ii  libedataserver1.2-11
> > 2.30.1-3  Utility library for evolution data
> 
> Looking at the end of your strace output, I wonder if the problem
> might be related to versions of these packages.  I have the squeeze
> version for all three; I won't be able to try the sid ones
> immediately. You seem to have a mixture of squeeze and sid versions
> here.
Indeed, I have downgraded the mixture to squeeze (to 2.28.* version)
packages and now it seems to create the configuration directory. I will
be able to test a full sid version tomorrow.

Thanks for pointing this out.

Jan




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

Bug#573166: libkexiv2-7: libkexiv2 doesn't extract language alternative value correctly

[Jan Capek]

Package: libkexiv2-7
Version: 4:4.3.4-1
Severity: normal
Tags: patch


The KExiv2::getXmpTagStringLangAlt() fails to extract a language
alternative value, no matter what the specified language alternative
is. A detailed description how I came across this problem is described
@ https://bugs.kde.org/show_bug.cgi?id=199317 - a result of using
kipi-plugins.

Please, consider the attached patch for the Debian package until it is
accepted/reworked upstream.

The patch itself has a header describing all the implementation
details.

Thank you,

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

Kernel: Linux 2.6.30-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libkexiv2-7 depends on:
ii  kdelibs5  4:4.3.4-3  core libraries for all KDE 4 appli
ii  libc6 2.10.2-2   GNU C Library: Shared libraries
ii  libexiv2-60.19-1 EXIF/IPTC metadata manipulation li
ii  libgcc1   1:4.4.2-9  GCC support library
ii  libqtcore44:4.5.3-4  Qt 4 core module
ii  libqtgui4 4:4.5.3-4  Qt 4 GUI module
ii  libstdc++64.4.2-9The GNU Standard C++ Library v3

libkexiv2-7 recommends no packages.

libkexiv2-7 suggests no packages.

-- no debconf information
Language alternative accessor fix (KExiv2::getXmpTagStringLangAlt())

- removed broken code that was using toString(long index) method of
  the iterator to extract a particular language alternative
  value. This maybe a bug in libexiv2, however, there is no need for
  handwritten parsing of the value via detectLanguageAlt() since
  libexiv2 provides all the necessary functionality for this - see the
  next point

- the proposed mechanism iterates through all language alternatives
  stored in an Exiv2::LangAltValue instance and selects only the
  requested one

- NOTE: the implementation of KExiv2::getXmpTagStringLangAlt() may
  also use getXmpTagStringListLangAlt() to extract the list of
  language alternatives into a hash map and then extract only the
  relevant item from it. This would be slightly slower but a much
  nicer code ;-).
Index: kdegraphics-4.3.4/libs/libkexiv2/libkexiv2/kexiv2xmp.cpp
===
--- kdegraphics-4.3.4.orig/libs/libkexiv2/libkexiv2/kexiv2xmp.cpp
+++ kdegraphics-4.3.4/libs/libkexiv2/libkexiv2/kexiv2xmp.cpp
@@ -420,19 +420,22 @@ QString KExiv2::getXmpTagStringLangAlt(c
 {
 Exiv2::XmpData xmpData(d->xmpMetadata);
 Exiv2::XmpKey key(xmpTagName);
-for (Exiv2::XmpData::iterator it = xmpData.begin(); it != 
xmpData.end(); ++it)
+/* TODO: we should consider using getXmpTagStringListLangAlt() method 
and extract only the
+ * requested language alternative. This would allow eliminating all 
this code but would
+ * become more memory intensive. In reality, how many language 
alternatives users have..? */
+for (Exiv2::XmpData::const_iterator it = xmpData.begin(); it != 
xmpData.end(); ++it)
 {
 if (it->key() == xmpTagName && it->typeId() == Exiv2::langAlt)
 {
-for (int i = 0; i < it->count(); i++)
-{
-std::ostringstream os;
-os << it->toString(i);
-QString lang;
-QString tagValue = QString::fromUtf8(os.str().c_str());
-tagValue = detectLanguageAlt(tagValue, lang);
+const Exiv2::LangAltValue &lav =  dynamic_cast(it->value());
+for(std::map::const_iterator lit = 
lav.value_.begin();
+lit != lav.value_.end(); ++lit) {
+QString lang = QString::fromUtf8(lit->first.c_str());
+QString tagValue = QString::fromUtf8(lit->second.c_str());
 if (langAlt == lang)
 {
+kDebug(51003) << "Extracting XMP tag='" << xmpTagName 
<< "' lang='" << lang << "' value='"
+  << tagValue << "'" << endl;
 if (escapeCR)
 tagValue.replace("\n", " ");
 

Bug#564574: kipi-plugins: Fixes for the missing caption problem

[Jan Capek]

Package: kipi-plugins
Version: 1.1.0-1
Followup-For: Bug #564574

I have provided sample fix for this problem, please, see
https://bugs.kde.org/show_bug.cgi?id=199317 for details.

The first patch (fb-caption-hack) is not suitable for inclusion into
the Debian package but gives hints how to fix it.

The second patch (lang-alt-fix) is for libkexiv2 that is part of
kdegraphics package. I am filing a bug against it now, so that this
workaround can be included in Debian.

Best regards,

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

Kernel: Linux 2.6.30-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages kipi-plugins depends on:
ii  kdebase-runtime4:4.3.4-2 runtime components from the offici
ii  kdelibs5   4:4.3.4-3 core libraries for all KDE 4 appli
ii  kdepimlibs54:4.3.4-2 core libraries for KDE PIM 4 appli
ii  libc6  2.10.2-2  GNU C Library: Shared libraries
ii  libexpat1  2.0.1-7   XML parsing C library - runtime li
ii  libgcc11:4.4.2-9 GCC support library
ii  libgl1-mesa-glx [libgl 7.6.1-1   A free implementation of the OpenG
ii  libglu1-mesa [libglu1] 7.6.1-1   The OpenGL utility library (GLU)
ii  libice62:1.0.6-1 X11 Inter-Client Exchange library
ii  libjpeg62  6b-16.1   The Independent JPEG Group's JPEG 
ii  libkdcraw7 4:4.3.4-1+b1  RAW picture decoding C++ library (
ii  libkexiv2-74:4.3.4-1 Qt like interface for the libexiv2
ii  libkipi6   4:4.3.4-1+b1  library for apps that want to use 
ii  libksane0  4:4.3.4-1+b1  scanner library for KDE 4 (runtime
ii  libphonon4 4:4.5.3-4 Qt 4 Phonon module
ii  libpng12-0 1.2.42-2  PNG library - runtime
ii  libqca22.0.2-1   libraries for the Qt Cryptographic
ii  libqt4-dbus4:4.5.3-4 Qt 4 D-Bus module
ii  libqt4-network 4:4.5.3-4 Qt 4 network module
ii  libqt4-opengl  4:4.5.3-4 Qt 4 OpenGL module
ii  libqt4-svg 4:4.5.3-4 Qt 4 SVG module
ii  libqt4-xml 4:4.5.3-4 Qt 4 XML module
ii  libqtcore4 4:4.5.3-4 Qt 4 core module
ii  libqtgui4  4:4.5.3-4 Qt 4 GUI module
ii  libsm6 2:1.1.1-1 X11 Session Management library
ii  libstdc++6 4.4.2-9   The GNU Standard C++ Library v3
ii  libtiff4   3.9.2-3+b1Tag Image File Format (TIFF) libra
ii  libx11-6   2:1.3.2-1 X11 client-side library
ii  libxau61:1.0.5-1 X11 authorisation library
ii  libxdmcp6  1:1.0.3-1 X11 Display Manager Control Protoc
ii  libxext6   2:1.1.1-2 X11 miscellaneous extension librar
ii  libxml22.7.6.dfsg-1  GNOME XML library
ii  libxrandr2 2:1.3.0-3 X11 RandR extension library
ii  libxslt1.1 1.1.24-2  XSLT processing library - runtime 
ii  phonon 4:4.5.3-4 Qt 4 Phonon module metapackage
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime

Versions of packages kipi-plugins recommends:
ii  graphicsmagick-imagemagick-co 1.1.11-3.1 image processing tools providing I
ii  konqueror 4:4.3.4-1  KDE 4's advanced file manager, web

Versions of packages kipi-plugins suggests:
pn  gallery(no description available)
ii  gimp  2.4.7-1The GNU Image Manipulation Program
pn  kmail  (no description available)
pn  vorbis-tools   (no description available)

-- 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#381280: No more access from remote clients after upgrade. 'cupsdAuthorize: No authentication data provided.'

[Jan Capek]

Package: cups
Version: 1.3.10-1
Followup-For: Bug #381280

After upgrading to 1.3.10-1 all remote clients on the local network
were not able to use the CUPS server anymore

The first issue was that the clients didn't see the published printers
anymore. The fix in the configuration file was trivial - just followed
the manpage. Probably, some default has changed. The following snippet
fixed the problem and clients were able to browse the printers again:

# this enables broadcasting the printer information on all local
# interfaces
BrowseAddress @LOCAL
BrowseAllow @LOCAL

The second issue was that none of the clients was given access to the
printers. After investigation of the error log (debug level) I noticed
the 'No authentication data provided' message. This error message was
being emitted anytime the client tried even polling the printer
(e.g. by clicking on the printer in the browser of the remote client).
After some googling I didn't find any solution. There were only people
that had this error and it started magically to work after a series of
upgrades - not my case... Apparently, the default security policy of
CUPS must have changed and remote clients were no longer allowed to
perform any of the operation as before. The following snippet fixed
the problem and clients are able to print now:

# Restrict access to the server...

  AuthType None
  Order allow,deny
  Allow from @LOCAL


The rest of the configuration file (admin locations + default policy
etc.) takes care of restricting the remote clients from doing anything
else but printing and managing their jobs (default provided by the
package).

Eventhough my problem has been fixed by adjusting the configuration,
the error log still contains the 'No authentication data provided'
message. To me, it looks like it is more of a warning that the client
simply didn't send any auth. data and cups will act accordingly and
would provide access that doesn't require authentication..

Hope this would save somebody's time and frustration after CUPS
upgrade.. For completeness, I am attaching my configuration file.

Cheers,

Jan


*** /tmp/reportbug-cups-20090521-25558-dMlks7
Content-Type: multipart/mixed; boundary="===1766670036487845632=="
MIME-Version: 1.0
From: Jan Capek 
To: Debian Bug Tracking System <381...@bugs.debian.org>
Subject: No more access from remote clients after upgrade. 'cupsdAuthorize: No
 authentication data provided.'
Message-ID: <20090520224626.25558.12234.report...@localhost>
X-Mailer: reportbug 3.45
Date: Thu, 21 May 2009 00:46:26 +0200
X-Debbugs-Cc: jan-deb...@capkovi.eu

This is a multi-part MIME message sent by reportbug.


--===1766670036487845632==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Package: cups
Version: 1.3.10-1
Followup-For: Bug #381280

After upgrading to 1.3.10-1 all remote clients on the local network
were not able to use the CUPS server anymore

The first issue was that the clients didn't see the published printers
anymore. The fix in the configuration file was trivial - just followed
the manpage. Probably, some default has changed. The following snippet
fixed the problem and clients were able to browse the printers again:

# this enables broadcasting the printer information on all local
# interfaces
BrowseAddress @LOCAL
BrowseAllow @LOCAL

The second issue was that none of the clients was given access to the
printers. After investigation of the error log (debug level) I noticed
the 'No authentication data provided' message. This error message was
being emitted anytime the client tried even polling the printer
(e.g. by clicking on the printer in the browser of the remote client).
After some googling I didn't find any solution. There were only people
that had this error and it started magically to work after a series of
upgrades - not my case... Apparently, the default security policy of
CUPS must have changed and remote clients were no longer allowed to
perform any of the operation as before. The following snippet fixed
the problem and clients are able to print now:

# Restrict access to the server...

  AuthType None
  Order allow,deny
  Allow from @LOCAL


The rest of the configuration file (admin locations + default policy
etc.) takes care of restricting the remote clients from doing anything
else but printing and managing their jobs (default provided by the
package).

Eventhough my problem has been fixed by adjusting the configuration,
the error log still contains the 'No authentication data provided'
message. To me, it looks like it is more of a warning that the client
simply didn't send any auth. data and cups will act accordingly and
would provide access that doesn't require authentication..

Hope this would save somebody's time and frustration after CUPS
upgrade..

Cheers,

Jan

Bug#490410: [Pkg-xfce-devel] Bug#490410: Bug#490410: Bug#490410: xfce4-xkb-plugin: Same issue with us, cz keyboard layout, more details, workaround

[Jan Capek]

On Fri, 10 Oct 2008, Yves-Alexis Perez wrote:

> On Wed, Oct 08, 2008 at 09:58:15AM +0200, Jan Capek wrote:
> > I want to point out that I have two independent computers here:
> > 
> > 1) laptop - uses gdm to start xfce4
> > 2) server - has no gdm installed and I launch xfce4 manually (startx)
> > 
> > Both are experiencing the same issue. I am willing to debug further. 
> > However, it has been more than a month and I forgot some of the internals 
> > I saw in the keyboard plugin. Would it help if I post here the exact 
> > mechanism how the plugin gets the keyboard layout information from X? 
> > Maybe somebody w/ better knowledge of X could direct us.
> 
> Yes it'd be nice to do some kind of summary, it's becoming a bit messy.
> Which xorg do your run, btw? Could you give us the result of dpkg -l |
> grep xorg?
> 
> Cheers,
> -- 
> Yves-Alexis
> 
Hi,

one more update, I have performed dist upgrade, below are the latest 
package versions and it seems to make no difference either. This is the 
machine that uses 'startx' to start the server and no display manager.

Cheers,

Jan


ii  xorg1:7.3+18   X.Org X 
Window System
ii  xorg-docs   1:1.4-3
Miscellaneous documentation for the X.Org software suite
ii  xserver-xorg1:7.3+18   the 
X.Org X server
ii  xserver-xorg-core   2:1.4.2-7  Xorg X 
server - core server
ii  xserver-xorg-input-all  1:7.3+18   the 
X.Org X server -- input driver metapackage
ii  xserver-xorg-input-evdev1:2.0.3-1  X.Org X 
server -- evdev input driver
ii  xserver-xorg-input-kbd  1:1.3.1-1  X.Org X 
server -- keyboard input driver
ii  xserver-xorg-input-mouse1:1.3.0-1  X.Org X 
server -- mouse input driver
ii  xserver-xorg-input-synaptics0.14.7~git20070706-3   
Synaptics TouchPad driver for X.Org/XFree86 server
ii  xserver-xorg-input-wacom0.8.0.2-2  X.Org X 
server -- Wacom input driver
ii  xserver-xorg-video-radeon   1:6.9.0-1+lenny4   X.Org X 
server -- ATI Radeon display driver
ii  xserver-xorg-video-radeonhd 1.2.1-2X.Org X 
server -- AMD/ATI r5xx, r6xx display driver
ii  xserver-xorg-video-v4l  0.2.0-1X.Org X 
server -- Video 4 Linux display driver




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

Bug#490410: [Pkg-xfce-devel] Bug#490410: Bug#490410: xfce4-xkb-plugin: Same issue with us, cz keyboard layout, more details, workaround

[Jan Capek]

> > 
> > Please, note that it if I specify e.g. 'de,cz' instead of 'us,cz' in
> > the 
> > xorg.conf, the xfce4-panel would start the plugin but the plugin would
> > see 
> > the default 'us' layout. I am wondering if this whole thing could be
> > some 
> > unfortunate synchronization issue during the whole startup sequence
> > that 
> > causes the plugin to get the wrong information from X..
> 
> The thing is, the display started from gdm belongs to X, while later
> it's owned by $user. In startxfce4 case it's owned directly by $user.
> 
> I'm not really sure what happens here…

I want to point out that I have two independent computers here:

1) laptop - uses gdm to start xfce4
2) server - has no gdm installed and I launch xfce4 manually (startx)

Both are experiencing the same issue. I am willing to debug further. 
However, it has been more than a month and I forgot some of the internals 
I saw in the keyboard plugin. Would it help if I post here the exact 
mechanism how the plugin gets the keyboard layout information from X? 
Maybe somebody w/ better knowledge of X could direct us.

Cheers,

Jan

Bug#490410: [Pkg-xfce-devel] Bug#490410: xfce4-xkb-plugin: Same issue with us, cz keyboard layout, more details, workaround

[Jan Capek]

Hi,

On Wed, 8 Oct 2008, Yves-Alexis Perez wrote:

> On mer, 2008-09-17 at 03:04 +0300, Andrei Popescu wrote:
> > > > 
> > > > Could you try:
> > > > - start X and Xfce and don't type anything (for example using
> > startx
> > > >   /usr/bin/startxfce4)
> > > 
> > > This still gives me the problem, where the plugin loads only the
> > US 
> > > keyboard, not reflecting what is in xorg.conf
> >  
> > Confirmed (this is also my default)
> > 
> > > > - start X, type some stuff, then start xfce4-panel (for example
> > using
> > > >   gdm or any dm)
> > > X is started via gdm, there are tons of characters typed when
> > logging 
> > > in. Layout switching is already active there and works (tested).
> > Then 
> > > after successful login xfce is started (probably via Xsession.d
> > and 
> > > that whole path - not an expert here) and the xkb plugin is
> > still 
> > > confused. I hope I understood this test correctly.
> > 
> > Not confirmed. For me it works ok when using gdm.
> 
> Andrei:
> Ok so in your case, your hitting the “no keypress before init”. Not sure
> if there's already a bug opened, I'll point you to it later.
> 
> Jan:
> For your case, that's another story, and thus another bug. What puzzles
> me is that when you described the situation in your first mail, it was
> kind of exactly that (no init before keypresses).
> When you say that layout switching is working *before* Xfce is run, how
> do you try that?
I meant the gdm - which is already an instance of X, right? In the login 
dialogue in gdm, I am able to switch keyboard layouts using the shortcut 
specified in my xorg.conf (see below for the relevant snippet).

Cheers,

Jan


relevant part of my xorg.conf:

-
Section "InputDevice"
Identifier  "Generic Keyboard"
Driver  "kbd"
Option  "XkbRules"  "xorg"
Option  "XkbModel"  "microsoftprousb"
Option  "XkbLayout" "us,cz"
Option  "XkbVariant"",qwerty"
Option  "XkbOptions"
"grp:alt_shift_toggle,grp_led:scroll"
EndSection
-

Please, note that it if I specify e.g. 'de,cz' instead of 'us,cz' in the 
xorg.conf, the xfce4-panel would start the plugin but the plugin would see 
the default 'us' layout. I am wondering if this whole thing could be some 
unfortunate synchronization issue during the whole startup sequence that 
causes the plugin to get the wrong information from X..

Bug#490410: [Pkg-xfce-devel] Bug#490410: Bug#490410: xfce4-xkb-plugin: Same issue with us, cz keyboard layout, more details, workaround

[Jan Capek]

> Ok. Can you tell me how do you start Xfce? Julien Cristeau (XSF Dev)
> said me that it could be because of the lack of keypresses before plugin
> initialization.
I normally start Xfce by 'startx' on my machine. However, on my parent's 
machine Xfce is being started through gdm. So, the results:
> 
> Could you try:
> - start X and Xfce and don't type anything (for example using startx
>   /usr/bin/startxfce4)

This still gives me the problem, where the plugin loads only the US 
keyboard, not reflecting what is in xorg.conf

> - start X, type some stuff, then start xfce4-panel (for example using
>   gdm or any dm)
X is started via gdm, there are tons of characters typed when logging 
in. Layout switching is already active there and works (tested). Then 
after successful login xfce is started (probably via Xsession.d and 
that whole path - not an expert here) and the xkb plugin is still 
confused. I hope I understood this test correctly.

One more interesting note. I have tried using fbxkb and that one gives yet 
another broken result: unlike xfce's xkb plugin, it doesn't display the US 
flag at all, only '??'. The Czech one is correct. It doesn't make any 
difference whether I restart it or not. I don't care though. I would like 
the xfce's xkb indicator working.

Cheers,

Jan

> 
> And report us what the result are.
> 
> Cheers,
> -- 
> Yves-Alexis
> 




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

Bug#490410: [Pkg-xfce-devel] Bug#490410: xfce4-xkb-plugin: Same issue with us, cz keyboard layout, more details, workaround

[Jan Capek]

Hi,

thanks for feedback, see below.

On Sun, 17 Aug 2008, Yves-Alexis Perez wrote:

> On sam, 2008-08-16 at 22:33 +0200, Jan Capek wrote:
> > The contents of these arrays differs depending on whether the 
> > instance of the xkb plugin comes from a the actual startup of the
> > entire 
> > xfce4 environment or if I RESTART xfce4panel.
> 
> Could you try to save your session without saving, or something like
> that, to enter the session without any panel running. Then wait a bit,
> and run xfce4-panel, and see if you're in the START case or in the
> RESTART case.
I have tried this and that works as expected that is START case is the 
same as RESTART case. So it still looks like some crap in the actual 
xkb stuff.

> 
> It may be related to http://bugzilla.xfce.org/show_bug.cgi?id=3156 but
> in your case you already use us,cz.
Yes, this is the original that I started wondering about - cz,us from 
xorg.conf makes the US layout broken as I describe on bugzilla (posted 
yesterday) - us, cz is fine.

I had one more idea for testing - I have specified only two exotic layouts 
in my xorg.conf, omitting the US one completely:
Section "InputDevice"
Identifier  "Generic Keyboard"
Driver  "kbd"
Option  "XkbRules"  "xorg"
Option  "XkbModel"  "microsoftprousb"
Option  "XkbLayout" "de,cz"
Option  "XkbVariant"",qwerty"
Option  "XkbOptions"
"grp:alt_shift_toggle,grp_led:scroll"
EndSection

... and guess what happened.., the xkb plugin upon xfce4 START 
showing the US flag only and layout change makes it display either (null) 
or the US flag. So, this only confirms the theory that for some 
reason the plugin/panel is not started at the time when the layouts have 
been loaded by the X server, ugh. Whose fault is this?

As of the bug http://bugzilla.xfce.org/show_bug.cgi?id=3156, should this 
be escalated to xserver-xorg-input-kbd driver? This clearly seems to 
be some xkbd problem.

I am relocating tomorrow, so I will be able to perform further 
tests/answer questions on wednesday.

Cheers,

Jan

> 
> Cheers,
> -- 
> Yves-Alexis
> 




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

Bug#490410: xfce4-xkb-plugin: Same issue with us, cz keyboard layout, more details, workaround

[Jan Capek]

Package: xfce4-xkb-plugin
Version: 0.4.3-1
Followup-For: Bug #490410

Hi,

I have just experienced the same bug using a combination of us and cs 
layout. This is the relevant part of the my xorg.conf:
Section "InputDevice"
Identifier  "Generic Keyboard"
Driver  "kbd"
Option  "XkbRules"  "xorg"
Option  "XkbModel"  "microsoftprousb"
Option  "XkbLayout" "us,cz"
Option  "XkbVariant"",qwerty"
Option  "XkbOptions"
"grp:alt_shift_toggle,grp_led:scroll"
EndSection

I have played with the sources a bit and have loaded the xkb plugin into 
gdb and have found out the following:

- upon startup in xkb.c::initialize_xkb(), the plugin tries to fill two 
arrays(group_names and symbol_names) based on data provided by the xkb 
extension. The contents of these arrays differs depending on whether the 
instance of the xkb plugin comes from a the actual startup of the entire 
xfce4 environment or if I RESTART xfce4panel.

- after launching xfce4 via startx. The arrays contain information for 
the US keyboard only:
(gdb) p group_names
$16 = {0x1819eb0 "USA", 0x0, 0x0, 0x0}
(gdb) p symbol_names 
$18 = {0x181a410 "US", 0x0, 0x0, 0x0}
(gdb) c
Continuing.

- after restarting the xfce4-panel (thus reloading the xkb plugin), I 
can see the arrays already contain the expected values:
Breakpoint 11, handle_xevent (ctrl=0x1541ef0) at xkb.c:411
(gdb) p group_names 
$19 = {0x1581f80 "USA", 0x1581de0 "Czechia - qwerty", 0x0, 0x0}
(gdb) p symbol_names 
$20 = {0x1582570 "US", 0x1582590 "CZ", 0x0, 0x0}


Could this be some kind of race between the X server loading both 
layouts and the xfce4 startup, or something like that? The plugin's 
initialization function that loads the above arrays is very messy and 
seems to contain quite a few hacks and workaround. I can investigate 
further but I am not an xkb guru.

Actually, I currently need some workaround for this - something like 
restart xfce4-panel as xfce4 runs on my parent's machine and they are 
really getting confused on seeing (null) instead of the flag..

Best regards and thanks for any info,

Jan


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

Kernel: Linux 2.6.26-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages xfce4-xkb-plugin depends on:
ii  libatk1.0-0   1.22.0-1   The ATK accessibility toolkit
ii  libc6 2.7-13 GNU C Library: Shared libraries
ii  libcairo2 1.6.4-6The Cairo 2D vector graphics libra
ii  libfontconfig12.6.0-1generic font configuration library
ii  libglib2.0-0  2.16.5-1   The GLib library of C routines
ii  libgtk2.0-0   2.12.11-3  The GTK+ graphical user interface 
ii  libpango1.0-0 1.20.5-1   Layout and rendering of internatio
ii  libx11-6  2:1.1.4-2  X11 client-side library
ii  libxcursor1   1:1.1.9-1  X cursor management library
ii  libxext6  2:1.0.4-1  X11 miscellaneous extension librar
ii  libxfce4util4 4.4.2-3Utility functions library for Xfce
ii  libxfcegui4-4 4.4.2-4Basic GUI C functions for Xfce4
ii  libxfixes31:4.0.3-2  X11 miscellaneous 'fixes' extensio
ii  libxi62:1.1.3-1  X11 Input extension library
ii  libxinerama1  2:1.0.3-2  X11 Xinerama extension library
ii  libxrandr22:1.2.3-1  X11 RandR extension library
ii  libxrender1   1:0.9.4-2  X Rendering Extension client libra
ii  xfce4-panel   4.4.2-6The Xfce4 desktop environment pane

xfce4-xkb-plugin recommends no packages.

xfce4-xkb-plugin suggests no packages.

-- no debconf information



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

Bug#495040: libflash-mozplugin: iceweasel crashes on loading http://www.rb.cz

[Jan Capek]

Package: libflash-mozplugin
Version: 0.4.13-9
Severity: grave
Justification: renders package unusable

The browser crashes when loading the above website. The website contains 
some components written in flash. I have verified that 
disabling/uninstalling the flash plugin eliminates the problem.

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

Kernel: Linux 2.6.26-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libflash-mozplugin depends on:
ii  libflash0c2   0.4.13-9   GPL Flash (SWF) Library - shared l

libflash-mozplugin recommends no packages.

libflash-mozplugin suggests no packages.

-- no debconf information



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

Bug#471677: cvs marks a release tag as a branch tag under CVS/Tag

[Jan Capek]

Package: cvs
Version: 1:1.12.13-10
Severity: normal


when working with a roughly 4 years old repository a checkout of
module using a release tag (named 'START') results in a working copy
where this tag is marked with 'T' prefix in CVS/Tag . The 'T' denotes
a branch tag. However, a tag prefixed with 'N' (non branch) was
actually expected.  The command used:

cvs -f -q -d /home/jca/old-cvsroot checkout -d testmodule -r START prj


Example output of 'cvs status -v file.c' shows that 'START' is really
a release tag:

File: machx.c  Status: Up-to-date

   Working revision:   1.1.1.1 2004-07-19 23:52:57 +0200
   Repository revision:1.1.1.1 /home/jca/old-cvsroot/prj/file.c,v
   Commit Identifier:  (none)
   Sticky Tag:  START (revision: 1.1.1.1)
   Sticky Date:   (none)
   Sticky Options:(none)

   Existing Tags:
   REL2004-08-12_ALL(revision: 1.2)
   START(revision: 1.1.1.1)
   capekj1  (branch: 1.1.1)


The content of CVS/Tag in the working copy is then 'TSTART'.

However, when I create a fresh new repository via cvs init, import etc
and perform a couple of commits. The above checkout of the release tag
is then correctly marked as a regular tag - 'NSTART'.  Both
repositories old/new when checking status of a particular file never
show the 'START' to be a branch tag.


I have come across this issue while converting the old cvs repository
to a mercurial using 'tailor'. Having an incorrectly marked tag makes the 
tailor tool fail to retrieve all changsets.


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.17.3 (PREEMPT)
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages cvs depends on:
ii  debconf [debconf-2.0]  1.5.19Debian configuration management sy
ii  libc6  2.7-9 GNU C Library: Shared libraries
ii  libpam-runtime 0.99.7.1-5Runtime support for the PAM librar
ii  libpam0g   0.99.7.1-5Pluggable Authentication Modules l
ii  update-inetd   4.29  inetd.conf updater
ii  zlib1g 1:1.2.3.3.dfsg-11 compression library - runtime

Versions of packages cvs recommends:
ii  emacs21 [info-browser]  21.4a+1-5.3  The GNU Emacs editor
ii  emacs22-gtk [info-brows 22.1+1-2.3   The GNU Emacs editor (with GTK use
ii  info [info-browser] 4.11.dfsg.1-4Standalone GNU Info documentation 
ii  konqueror [info-browser 4:3.5.8.dfsg.1-7 KDE's advanced file manager, web b
ii  netbase 4.30 Basic TCP/IP networking system

-- debconf information:
  cvs/pserver_repos_individual: true
  cvs/pserver_setspawnlimit: false
  cvs/rotatekeep: 7
  cvs/badrepositories: create
  cvs/rotatekeep_individual: 7
  cvs/pserver_repos: all
  cvs/pserver: false
  cvs/cvs_conf_is_dead:
  cvs/repositories: /var/lib/cvs
  cvs/rotatekeep_nondefault: no
  cvs/rotate_individual: true
  cvs/pserver_spawnlimit: 400
  cvs/rotatehistory: no



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

Bug#466687: [Pkg-xfce-devel] Bug#466687: Bug#466687: xfce4: windows are not being redrawn correctly when moving - nv/nvidia driver Xinerama, dualhead

[Jan Capek]

Yves-Alexis Perez wrote:

On Wed, Feb 27, 2008 at 04:02:12PM +, Jan Capek wrote:

Hi,

Yves-Alexis Perez wrote:

On jeu, 2008-02-21 at 18:21 +0100, Jan Capek wrote:

Disabling xinerama 'solves' the problem however at that point I am
stuck 
with 2 independent screens that are not of much use for me.

Ok.

I am not sure, maybe I should file a bug somewhere in the 'nv',
'nvidia' 
driver area. However, this bug seems to trigger with xfce4 only.

Well, could you try in metacity or openbox, wich support xinerama pretty
well?

I have tested with openbox. This allowed me identifying the problem a
little bit further. The issue is still reproducable in openbox when I
use the xfce4-terminal there. Further, I have noticed that when dragging 
any other windows over this terminal their decorations get damaged, too. 
Now I am quite sure that this is nvidia driver problem. There has to be 
some window redrawing function that xfce4 uses that triggers this bug.
Should this still be reported to xfce4 bts to work around for broken 
nvidia drivers?


Well, the xfce4-terminal thingy looks like a problem in compositing (or maybe
in vte). I know that I've asked multiple times yet, but is compositing
deactivated in xorg.conf? Like:

Section "Extensions" 
	Option "Composite" "Disable" 
EndSection
Oops, I have NOW explicitely disabled compositing and the redraw issues 
are gone. Well, I think you can close this issue. I am attaching a 
working configuration file for xorg, so that anybody having this probe 
is able to find a solution to it.


I would be more happy if there was some working solution for dualhead 
for nVidia GeForce 6200 so that I wouldn't have to use the proprietary 
driver. But as of now, I didn't find any, so I have struggle with this bug.


Yup, that's the problem with crappy proprietary and non documented hardware :(

I hate proprietary hardware, too..


Cheers,

Thanks a lot for support,

Jan


--
# xorg.conf (X.Org X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section "InputDevice"
Identifier  "Generic Keyboard"
Driver  "kbd"
Option  "CoreKeyboard"
Option  "XkbRules"  "xorg"
Option  "XkbModel"  "pc104"
Option  "XkbLayout" "us"
EndSection

Section "InputDevice"
Identifier  "Configured Mouse"
Driver  "mouse"
Option  "CorePointer"
Option  "Device""/dev/input/mice"
#   Option  "Protocol"  "ExplorerPS/2"
Option  "Protocol"  "IMPS/2"
EndSection

Section "Device"
Identifier  "NVIDIA Corporation NV44 [GeForce 6200 TurboCache] 0"
Driver  "nvidia"
BusID   "PCI:1:0:0"
Screen  0
EndSection
Section "Device"
Identifier  "NVIDIA Corporation NV44 [GeForce 6200 TurboCache] 1"
Driver  "nvidia"
BusID   "PCI:1:0:0"
Screen  1
EndSection

Section "Monitor"
Identifier  "LG L1730S"
Option  "DPMS"
HorizSync   28-80
VertRefresh 43-100
DisplaySize 345 259 # 17" screen dimensions
EndSection

Section "Screen"
Identifier  "Main Screen"
Device  "NVIDIA Corporation NV44 [GeForce 6200 TurboCache] 0"
Monitor "LG L1730S"
DefaultDepth24
SubSection "Display"
Depth   24
Modes   "1280x1024" "1024x768" "800x600" "640x480"
EndSubSection
EndSection

Section "Screen"
Identifier  "Second Screen"
Device  "NVIDIA Corporation NV44 [GeForce 6200 TurboCache] 1"
Monitor "LG L1730S"
DefaultDepth24
SubSection "Display"
Depth   24
Modes   "1280x1024" "1024x768" "800x600" "640x480"
EndSubSection
EndSection


Section "ServerLayout"
Identifier  "Default Layout"
Screen  0 "Main Screen"
Screen  1 "Second Screen" RightOf "Main Screen"
Option  "Xinerama" "True"
InputDevice "Generic Keyboard"
InputDevice "Configured Mouse"
EndSection
Section "Extensions" 
Option "Composite" "Disable" 
EndSection

Bug#467462: temporary workaround exists?

[Jan Capek]

Is there any temporary workaround as I quickly need to upgrade my system 
from etch.

Thanks,

Jan




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

Bug#466687: [Pkg-xfce-devel] Bug#466687: xfce4: windows are not being redrawn correctly when moving - nv/nvidia driver Xinerama, dualhead

[Jan Capek]

Hi,

Yves-Alexis Perez wrote:

On jeu, 2008-02-21 at 18:21 +0100, Jan Capek wrote:

Disabling xinerama 'solves' the problem however at that point I am
stuck 
with 2 independent screens that are not of much use for me.


Ok.

I am not sure, maybe I should file a bug somewhere in the 'nv',
'nvidia' 
driver area. However, this bug seems to trigger with xfce4 only.


Well, could you try in metacity or openbox, wich support xinerama pretty
well?

I have tested with openbox. This allowed me identifying the problem a
little bit further. The issue is still reproducable in openbox when I
use the xfce4-terminal there. Further, I have noticed that when dragging 
any other windows over this terminal their decorations get damaged, too. 
Now I am quite sure that this is nvidia driver problem. There has to be 
some window redrawing function that xfce4 uses that triggers this bug.
Should this still be reported to xfce4 bts to work around for broken 
nvidia drivers?






I have made a research and tried the following configurations for
dual 
head so far:

- nvidia driver (2 instances of the device) + Xinerama - this gives
me 
satisfying performance, however the above bug occurs in xfce4


- nvidia driver + TwinView option (X.org's xinerama is disabled) -
this 
works fine, however, the performance is VERY BAD. Moving windows
around 
is fine. Switching desktop and redrawing of all windows on the
freshly 
switched desktop is very very slow


- nv driver - doesn't support dual head on my nvidia card, xrandr 
extension doesn't show all connected screens. I will take a look at
the 
problem further here.


Well, I guess the problem lies in nvidia driver. I use at work two
nvidia-based cards, using xinerama, and it works pretty fine in Xfce (no
bug like this). But this is using nvidia legacy.


If anybody can think of a testcase, to duplicate the issue in a 
different environment than xfce4, I would be more than happy to try

that.

I am attaching the two configurations + xrandr output of the twinview 
one + relevant X.org logs.


The thing is, we can't really debug nvidia proprietary driver...


I would be more happy if there was some working solution for dualhead 
for nVidia GeForce 6200 so that I wouldn't have to use the proprietary 
driver. But as of now, I didn't find any, so I have struggle with this bug.


Jan




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

Bug#466687: [Pkg-xfce-devel] Bug#466687: xfce4: windows are not being redrawn correctly when moving

[Jan Capek]

Yves-Alexis Perez wrote:

severity #466687 normal
reassign #466687 xfwm4
thanks

On Wed, Feb 20, 2008 at 12:32:32PM +, Jan Capek wrote:

Application windows are being redrawn incorrectly when moving them
around the desktop. After minimizing such a broken window on the task
bar and putting it back to the foreground it will get rendered
properly. Could this be more of a GTK issue?  This problem doesn't
occur when using different window managers (tested w/ icewm,
fvwm). So, this should eliminate any issues w/ X.org and nvidia driver
itself. Attached is a screenshot of the desktop.  I am currently using
a dual head setup with xinerama and nvidia proprietary driver.


Can you retry this with the nv or vesa driver? Is compositing enabled?
I will try w/ the above drivers if I get them to work. Nv doesn't seem 
to work with xinerama. Compositing is not enabled.


Can you retry without xinerama too?

This is already with xinerama.


I never saw this kind of problem, so I don't really know what could happen.
Does this happen since the beginning? Did you change something?
This was the first time I had xfce4 on my machine at work. I have been 
using xfce4 on my laptop for a while and have never experienced such a 
problem.


Cheers,


Jan



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

Bug#463201: [Pkg-trac-devel] Bug#463201: trac: integratation of the new upstream version - 0.11

[Jan Capek]

On Wed, 30 Jan 2008, W. Martin Borgert wrote:

> On Wed, Jan 30, 2008 at 01:53:37PM +0900, Jan Capek wrote:
> > Would it be possible to integrate the new upstream version of trac? 
> 
> Hey, 0.11 is not yet released, there is only 0.11b1 (a beta
> version in feature freeze). The Debian maintainer could decide,
> that this beta is "good enough", however.
Another issue is that this update should go in sync with trac-mercurial 
plugin.

Let's see how the maintainer decides.

Jan



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

Bug#463201: trac: integratation of the new upstream version - 0.11

[Jan Capek]

Package: trac
Version: 0.10.4-2
Severity: wishlist

Would it be possible to integrate the new upstream version of trac? 

What would be the expected date when it would show up in debian?

Thanks

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-pty-2 (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/bash

Versions of packages trac depends on:
ii  python  2.4.4-6  An interactive high-level object-o
ii  python-clearsilver  0.10.4-1 python bindings for clearsilver
ii  python-pysqlite22.3.5-1  python interface to SQLite 3
ii  python-subversion   1.4.4dfsg1-1 Python bindings for Subversion
ii  python-support  0.7.5automated rebuilding support for p
ii  subversion  1.4.4dfsg1-1 Advanced version control system

Versions of packages trac recommends:
ii  apache2   2.2.8-1Next generation, scalable, extenda
ii  apache2-mpm-worker [httpd]2.2.8-1High speed threaded model for Apac
ii  python-setuptools 0.6c7-1Python Distutils Enhancements

-- no debconf information



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

Bug#461763: motion's init script hangs on startup

[Jan Capek]

Package: motion
Version: 3.2.9-1
Severity: important

After package upgrade, the init motion daemon is
started in such a way it seems to hang in 
foreground and starts capturing immediately.
That way none of the sucessive init scripts will not
get executed. Below is a log after duplicating this issue
from command line directly.

[EMAIL PROTECTED]:/etc/init.d$ sudo /etc/init.d/motion start
Starting motion detection : motion
[0] Processing thread 0 - config file /etc/motion/motion.conf
[0] Motion 3.2.9 Started
[0] ffmpeg LIBAVCODEC_BUILD 3352064 LIBAVFORMAT_BUILD 3344896
[0] Thread 1 is from /etc/motion/motion.conf
[1] Thread 1 started
[0] motion-httpd/3.2.9 running, accepting connections
[0] motion-httpd: waiting for data on port TCP 8080
[1] Not a V4L2 device?
[1] Using VIDEO_PALETTE_YUV420P palette
[1] Using V4L1
[1] Started stream webcam server in port 8081
[1] File of type 8 saved to: /tmp/motion/01-20080121012518.swf
[

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.23.14-jca (PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages motion depends on:
ii  adduser  3.105   add and remove users and groups
ii  debconf [debconf-2.0]1.5.18  Debian configuration management sy
ii  libavcodec1d 0.cvs20070307-6 ffmpeg codec library
ii  libavformat1d0.cvs20070307-6 ffmpeg file format library
ii  libavutil1d  0.cvs20070307-6 ffmpeg utility library
ii  libc62.7-6   GNU C Library: Shared libraries
ii  libjpeg626b-14   The Independent JPEG Group's JPEG 
ii  libmysqlclient15off  5.0.45-5MySQL database client library
ii  libpq5   8.2.5-4 PostgreSQL C client library

Versions of packages motion recommends:
ii  ffmpeg3:20071206-0.0 audio/video encoder, streaming ser

-- debconf information:
  motion/moved_conf_dir:



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