Bug#589855: p54pci doesn't work with ISL3890 based card
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
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
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
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
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
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.'
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
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
> > > > 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
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
> 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
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
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
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
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
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?
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
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
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
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
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
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]