Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv
Hello,
After some additional testing, checking my environment and inspecting pyuno/
source/loader/pyuno_loader.cxx, I want to amend the report, particularly about
7.0.4 which is not affected (kind of).
First, I wonder if someone reproduces this on 1:6.1.5-3+deb10u6 (if nobody
does, I may whip up a VM to exclude other factors next Sunday).
Indeed, however, on 1:7.0.4~rc2-1~bpo10+2 the issue is *NOT* reproducible (at
least with the given steps, see below), and was only happening entirely due to
a local misconfiguration, as I had a trailing colon inside PYTHONPATH. That
causes Python 3 to crash with that error. My deepest apologies for polluting
the report with the wrong information about 7.0.4.
However, I can still reproduce this on 6.1.5, and changing absolutely nothing
in the environment, including deletion of ~/.config/libreoffice does not seem
to stop it, and there is no PYTHONPATH set in any form. I also noticed that
pyuno/source/loader/pyuno_loader.cxx from the buster source does add exactly
such trailing colon (an issue that has been explicitly fixed in 7.0.4, so only
Buster is affected):
bufPYTHONPATH.append( systemPath );
bufPYTHONPATH.append( static_cast(SAL_PATHSEPARATOR) );
I see the code for buster-backports (and presumably bullseye) has been
modified to not leave either trailing colons or colons surrounding an empty
string by adding three explicit checks (except for one case, which threw off
my testing):
if (!systemPath.isEmpty())
{
if (bAppendSep)
bufPYTHONPATH.append(static_cast(SAL_PATHSEPARATOR));
bufPYTHONPATH.append(systemPath);
bAppendSep = true;
}
const char * oldEnv = getenv( "PYTHONPATH");
if( oldEnv )
{
if (bAppendSep)
bufPYTHONPATH.append( static_cast(SAL_PATHSEPARATOR)
);
bufPYTHONPATH.append( OUString(oldEnv, strlen(oldEnv),
osl_getThreadTextEncoding()) );
}
However, in spite of this fix, I was still able to reproduce a *similar*
(though significantly less impactful) issue on 7.0.4. Since the code checks if
PYTHONPATH is set (as opposed to empty), passing an empty PYTHONPATH causes
LibreOffice to crash in the same manner (while Python 3 itself does not).
With unset PYTHONPATH:
* 1:6.1.5-3+deb10u6 from Buster crashes
* 7.0.4 from Buster Backports and Bullseye DOES NOT crash
With *empty* PYTHONPATH both crash.
$ PYTHONPATH= localc ./test.csv # this triggers it on 7.0.4
$ localc ./test.csv # this triggers it on 6.1.5
Best wishes, and I again apologize for the missing report, and for reporting
an issue that is fixed (-ish) in bullseye and sid.
P.S. Yeah, LibreOffice doesn't touch encodings.py. The error is produced by
Python during initialisation as it tries to determine the locale encoding, so
it happens before any external Python code is executed, and only happens if
something injects the local directory or an empty string in PYTHONPATH.
On неделя, 7 март 2021 г. 22:14:02 EET Rene Engelhard wrote:
> tag 984703 + moreinfo
>
> tag 984703 + unreproducible
>
> thanks
>
>
> Hi,
>
> Am 07.03.21 um 13:34 schrieb Milko Krachounov:
> > When opening any CSV file with LibreOffice Calc, Calc opens and executes
> > encodings.py from the current working directory.
>
> Demonstrably wrong, see below.
>
> > That presumably happens because
> >
> > Some file managers, including Krusader and mc, would launch localc in the
> > current directory, as would running it from the command line (such as
> > `localc file.csv'), thereby running encodings.py from the directory
> > containing the file.
> >
> > The issue is not present when LibreOffice is launched through the
> > application launcher, and the file is opened later through whatever
> > means (neither Open file, nor through a file manager or the command
> > line, since localc already operates in one's $HOME in that instance)
> > To reproduce the issue, one needs to:
> > 1. Close LibreOffice *completely*
> > 2. In an empty directory, create "encodings.py" which raises an exception
>
> Created a encodings.py which contains "foo", which surely is not valid
> python.
>
> > 3. In the same directory (for simplicity), create "file.csv" with some
> >
> >rows.
>
> Did.
>
> 1,2
>
> ö,ä
>
>
> (last line to be sure there is some encoding in there)
>
> > 4. Open "file.csv" with `localc ./file.csv' using the directory containing
> >
> >"encodings.py" (double clicking in krusader and mc leads to the same
> >result)
>
> Done that.
>
> > The result is that LibreOffice crashes with the Python exception raised
> > by the rogue encodings.py, and then exits with an e
Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv
bus-glib-1-2 0.110-4 ii libdconf1 0.30.1-2 ii libeot0 0.01-5 ii libepoxy0 1.5.3-0.1 ii libexpat1 2.2.6-2+deb10u1 ii libexttextcat-2.0-0 3.4.5-1 ii libfontconfig12.13.1-2 ii libfreetype6 2.9.1-3+deb10u2 ii libgcc1 1:8.3.0-6 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgpgmepp6 1.12.0-6 ii libgraphite2-31.3.13-7 ii libharfbuzz-icu0 2.3.1-1 ii libharfbuzz0b 2.3.1-1 ii libhunspell-1.7-0 1.7.0-2 ii libhyphen02.8.8-7 ii libice6 2:1.0.9-2 ii libicu63 63.1-6+deb10u1 ii libjpeg62-turbo 1:1.5.2-2+deb10u1 ii liblcms2-22.9-3 ii libldap-2.4-2 2.4.47+dfsg-3+deb10u6 ii libmythes-1.2-0 2:1.2.4-3 ii libneon27-gnutls 0.30.2-3 ii libnspr4 2:4.20-1 ii libnss3 2:3.42.1-1+deb10u3 ii libnumbertext-1.0-0 1.0.5-1 ii libodfgen-0.1-1 0.1.7-1 ii liborcus-0.14-0 0.14.1-6 ii libpng16-16 1.6.36-6 ii libpoppler82 0.71.0-5 ii librdf0 1.0.17-1.1+b1 ii libreoffice-common1:6.1.5-3+deb10u6 ii librevenge-0.0-0 0.0.4-6 ii libsm62:1.2.3-1 ii libstdc++68.3.0-6 ii libx11-6 2:1.6.7-1+deb10u1 ii libxext6 2:1.3.3-1+b2 ii libxinerama1 2:1.1.4-2 ii libxml2 2.9.4+dfsg1-7+deb10u1 ii libxmlsec11.2.27-2 ii libxmlsec1-nss1.2.27-2 ii libxrandr22:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxslt1.11.1.32-2.2~deb10u1 ii uno-libs3 6.1.5-3+deb10u6 ii ure 6.1.5-3+deb10u6 ii zlib1g1:1.2.11.dfsg-1 Versions of packages libreoffice-core recommends: ii libpaper-utils 1.1.28 -- no debconf information On Sunday, 7 March 2021, 14:18:33 EET Salvatore Bonaccorso wrote: > Hi Milko, > > On Sat, Feb 27, 2021 at 08:36:31PM +0200, Milko Krachounov wrote: > > Package: libreoffice-calc > > Version: 1:6.1.5-3+deb10u6 > > Severity: grave > > Tags: security > > Justification: user security hole > > > > Dear Maintainer, > > > > When opening any CSV file with LibreOffice Calc, Calc opens and executes > > encodings.py from the current working directory. That presumably happens > > because > > > > Some file managers, including Krusader and mc, would launch localc in the > > current directory, as would running it from the command line (such as > > `localc file.csv'), thereby running encodings.py from the directory > > containing the file. > > > > The issue is not present when LibreOffice is launched through the > > application launcher, and the file is opened later through whatever > > means (neither Open file, nor through a file manager or the command > > line, since localc already operates in one's $HOME in that instance) > > > > To reproduce the issue, one needs to: > > 1. Close LibreOffice *completely* > > 2. In an empty directory, create "encodings.py" which raises an exception > > 3. In the same directory (for simplicity), create "file.csv" with some > > > >rows. > > > > 4. Open "file.csv" with `localc ./file.csv' using the directory containing > > > >"encodings.py" (double clicking in krusader and mc leads to the same > >result) > > > > The result is that LibreOffice crashes with the Python exception raised > > by the rogue encodings.py, and then exits with an error that reads: > > Fatal Python error: initfsencoding: Unable to get the locale encoding > > > > An offer is made to recover the unsaved file (but the list is empty), > > relaunching LO sometimes leads to new crashes. > > > > This is NOT the only way the issue happens, I was able to get the > > same crash while clicking through the menus or editing an .ods > > which initially didn't cause a crash, but those aren't deterministically > > reproduced, whereas the .csv route seems to guarantee a crash for me > > even when the .csv is ASCII. > > > > The problem is present in both Debian Stable (1:6.1.5-3+deb10u6), and > > Buster Backports (1:7.0.4~rc2-1~bpo10+2). No extensions not installed > > by apt are present on either machine (on the one with 6.1.5 I never > > installed any, and on the 7.0.4 I'm trusting what the LO extension > > manager is telling me, since I cannot recall for sure) > > > > Here's the console chatter: > > > > # Test on the
Bug#929362: icedtea-web: IcedTea plugin is gone, and Java applets no longer load in Konqueror web browser and co
Source: icedtea-web Version: 1.6.2-3.1+deb9u1 Severity: important Dear Maintainer, Since version 1.6.2-3.1+deb9u1 of the icedtea-web source package in Stretch, the icedtea-plugin is no longer built. As a result, NPAPI supporting browsers, which include Konqueror which is included in Stretch (and also any third party browsers such as SeaMonkey and Pale Moon) can no longer load Java applets. As a result, after upgrading to 1.6.2-3.1+deb9u1 we can no longer manage a certain batch of hardware requiring such (and that appears to be the only change in this new release). In addition, 1.6.2-3.1 has been removed from mirrors, and apt defaults to deleting /var/cache/apt/archives, so we cannot downgrade (SURPRISING NEW BEHAVIOURS ALL AROUND!) -- System Information: Debian Release: 9.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#909999: ghostscript (via pdf2ps) crashes on most inputs following upgrade to 9.06~dfsg-2+deb8u9
I can confirm this issue. Downgrading back to ghostscript_9.06~dfsg-2+deb8u8_amd64.deb ghostscript-x_9.06~dfsg-2+deb8u8_amd64.deb libgs9_9.06~dfsg-2+deb8u8_amd64.deb libgs9-common_9.06~dfsg-2+deb8u8_all.deb fixes the issue for me. Trying to convert a XeLaTeX-produced document leads to this error: $ pdf2ps article.pdf Error: /rangecheck in .installpagedevice Operand stack: --nostringval-- --dict:174/176(ro)(L)-- --nostringval-- --nostringval-- false Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1910 1 3 %oparray_pop 1909 1 3 %oparray_pop 1893 1 3 %oparray_pop --nostringval-- 1839 1 4 %oparray_pop --nostringval-- 1823 1 4 %oparray_pop --nostringval-- --nostringval-- Dictionary stack: --dict:939/1684(ro)(G)-- --dict:1/20(G)-- --dict:77/200(L)-- --dict:77/200(L)-- Current allocation mode is local GPL Ghostscript 9.06: Unrecoverable error, exit code 1
Bug#767353: [Pkg-clamav-devel] Bug#767353: clamav: ERROR: Can't save PID to file /var/run/clamav/freshclam.pid: No such file or directory
On Friday, 30 October 2014 22:14:46 you wrote: As this warning is completely harmless, when systemd is used, I don't think it's worth to invest a lot of time trying to fix this. It is not completely harmless---it breaks logrotate for me. Logrotate fails to reload the daemon after rotating the logs, and it spams my mailbox with errors. /etc/cron.daily/logrotate: pkill: pidfile not valid Try `pkill --help' for more information. And when running the post-rotate command that's in /etc/logrotate.d/clamav-freshclam I get the following: # /etc/init.d/clamav-freshclam reload-log [] Reloading ClamAV virus database updater: freshclampkill: pidfile not valid Try `pkill --help' for more information. failed! signature.asc Description: This is a digitally signed message part.
Bug#760191: Fixed
On 23 September 2014 09:15:32 Soren Stoutner wrote: An update to the latest packages from testing appears to have fixed this problem for me. I have not yet exhaustively checked for remaining errors, but I an now receiving new emails. Yes. The bug appears to be fixed now. After an upgrade the problem is gone for me as well, on both machines and with all three mail servers where I was experiencing the problem. I include the full list of packages that have been upgraded in the batch that fixed it. I realise it's a bit too extensive, but I'm not sure which packages might have caused the problem, so I include everything for reference. Also some packages aren't from the official Debian archives (they come from Deb Multimedia), but they are all unrelated to Akonadi and KMail. I hope they are not an issue. :) 2014-09-23 03:13:21 status installed dbus:amd64 1.8.6-2 2014-09-23 03:13:22 status installed man-db:amd64 2.6.7.1-1 2014-09-23 03:13:41 status installed hicolor-icon-theme:all 0.13-1 2014-09-23 03:13:42 status installed libmbim-glib0:amd64 1.8.0-1 2014-09-23 03:13:44 status installed libc-bin:amd64 2.19-11 2014-09-23 03:14:02 status installed man-db:amd64 2.6.7.1-1 2014-09-23 03:14:05 status installed menu:amd64 2.1.47 2014-09-23 03:14:09 status installed mime-support:all 3.56 2014-09-23 03:14:10 status installed desktop-file-utils:amd64 0.22-1 2014-09-23 03:14:12 status installed hicolor-icon-theme:all 0.13-1 2014-09-23 03:14:13 status installed libprotobuf8:amd64 2.5.0-9 2014-09-23 03:14:14 status installed libc-bin:amd64 2.19-11 2014-09-23 03:14:35 status installed man-db:amd64 2.6.7.1-1 2014-09-23 03:14:36 status installed menu:amd64 2.1.47 2014-09-23 03:14:37 status installed mime-support:all 3.56 2014-09-23 03:14:37 status installed desktop-file-utils:amd64 0.22-1 2014-09-23 03:14:40 status installed hicolor-icon-theme:all 0.13-1 2014-09-23 03:14:41 status installed libvlccore7:amd64 1:2.1.5-dmo2 2014-09-23 03:14:42 status installed libc-bin:amd64 2.19-11 2014-09-23 03:18:23 status installed man-db:amd64 2.6.7.1-1 2014-09-23 03:19:14 status installed shared-mime-info:amd64 1.3-1 2014-09-23 03:19:15 status installed libglib2.0-0:i386 2.40.0-5 2014-09-23 03:19:16 status installed libglib2.0-0:amd64 2.40.0-5 2014-09-23 03:19:19 status installed hicolor-icon-theme:all 0.13-1 2014-09-23 03:19:20 status installed mime-support:all 3.56 2014-09-23 03:19:21 status installed desktop-file-utils:amd64 0.22-1 2014-09-23 03:19:34 status installed cups:amd64 1.7.5-1 2014-09-23 03:19:35 status installed menu:amd64 2.1.47 2014-09-23 03:19:35 status installed dbus:amd64 1.8.6-2 2014-09-23 03:19:37 status installed doc-base:all 0.10.6 2014-09-23 03:19:45 status installed python-support:all 1.0.15 2014-09-23 03:19:47 status installed libmbim-glib4:amd64 1.10.0-2 2014-09-23 03:19:47 status installed libmbim-proxy:amd64 1.10.0-2 2014-09-23 03:19:48 status installed libmm-glib0:amd64 1.4.0-1 2014-09-23 03:19:48 status installed libqmi-glib1:amd64 1.10.2-2 2014-09-23 03:19:48 status installed libqmi-proxy:amd64 1.10.2-2 2014-09-23 03:19:50 status installed libprotobuf9:amd64 2.6.0-3 2014-09-23 03:19:51 status installed mosh:amd64 1.2.4a-1+b2 2014-09-23 03:19:51 status installed libphonenumber6:amd64 6.3~svn698-3+b1 2014-09-23 03:19:51 status installed libavutil54:amd64 10:2.4-dmo1 2014-09-23 03:19:52 status installed libavutil54:i386 10:2.4-dmo1 2014-09-23 03:19:52 status installed libmp3lame0:amd64 1:3.99.5-dmo3 2014-09-23 03:19:53 status installed libmp3lame0:i386 1:3.99.5-dmo3 2014-09-23 03:19:53 status installed libswresample1:i386 10:2.4-dmo1 2014-09-23 03:19:53 status installed libswresample1:amd64 10:2.4-dmo1 2014-09-23 03:19:54 status installed libx265-31:i386 1.3-dmo1 2014-09-23 03:19:54 status installed libzvbi0:i386 0.2.33-7 2014-09-23 03:19:55 status installed libavcodec56:i386 10:2.4-dmo1 2014-09-23 03:19:56 status installed libavcodec56:amd64 10:2.4-dmo1 2014-09-23 03:19:56 status installed libchromaprint0:amd64 1.2-dmo2 2014-09-23 03:19:56 status installed clementine:amd64 1.2.3+dfsg-2+b1 2014-09-23 03:19:57 status installed libavformat56:amd64 10:2.4-dmo1 2014-09-23 03:19:57 status installed liblircclient0:amd64 0.9.0~pre1-1.1 2014-09-23 03:19:58 status installed libpostproc53:amd64 10:2.4-dmo1 2014-09-23 03:19:59 status installed libswscale3:amd64 10:2.4-dmo1 2014-09-23 03:19:59 status installed libvcdinfo0:amd64 0.7.24+dfsg-0.2 2014-09-23 03:20:00 status installed vlc-data:all 1:2.2.0~pre3-dmo2 2014-09-23 03:20:00 status installed libvlccore8:amd64 1:2.2.0~pre3-dmo2 2014-09-23 03:20:01 status installed libvlc5:amd64 1:2.2.0~pre3-dmo2 2014-09-23 03:20:01 status installed vlc-nox:amd64 1:2.2.0~pre3-dmo2 2014-09-23 03:20:01 status installed vlc:amd64 1:2.2.0~pre3-dmo2 2014-09-23 03:20:02 status installed vlc-plugin-notify:amd64 1:2.2.0~pre3-dmo2 2014-09-23 03:20:02 status installed vlc-plugin-pulse:all 1:2.2.0~pre3-dmo2 2014-09-23 03:20:02 status installed phonon-backend-vlc:amd64 1:0.8.0-dmo2
Bug#760191: After upgrade 1.13.0-1 of akonadi-server, no new mail in IMAP folders is ever read
On 2014-09-10 12:17, Franz Schrober wrote: You provide nearly no information about your accounts or what you are doing. So please add more information. Is this the same problem as reported by me here or are you using a different setup: https://bugs.kde.org/show_bug.cgi?id=338967 The two servers that the problem occurs with are Courier IMAP on Debian Wheezy. I just noticed it doesn't occur with Gmail. After disabling TLS, here's the TCP traffic (with IP addresses removed) that I get when I try to refresh the folder: XXX.XXX.XXX.XXX.44030-YYY.YYY.YYY.YYY.00143: A34 EXPUNGE YYY.YYY.YYY.YYY.00143-XXX.XXX.XXX.XXX.44030: A34 OK EXPUNGE completed XXX.XXX.XXX.XXX.44030-YYY.YYY.YYY.YYY.00143: A35 SELECT INBOX YYY.YYY.YYY.YYY.00143-XXX.XXX.XXX.XXX.44030: * FLAGS ($MDNSent NonJunk $REPLIED $FORWARDED \Draft \Answered \Flagged \Deleted \Seen \Recent) * OK [PERMANENTFLAGS ($MDNSent NonJunk $REPLIED $FORWARDED \* \Draft \Answered \Flagged \Deleted \Seen)] Limited * 4260 EXISTS * 0 RECENT * OK [UIDVALIDITY 1056698153] Ok * OK [MYRIGHTS acdilrsw] ACL A35 OK [READ-WRITE] Ok XXX.XXX.XXX.XXX.44030-YYY.YYY.YYY.YYY.00143: A36 UID SEARCH UID 1:-1 YYY.YYY.YYY.YYY.00143-XXX.XXX.XXX.XXX.44030: A36 NO Error in IMAP command received by server. XXX.XXX.XXX.XXX.44030-YYY.YYY.YYY.YYY.00143: A37 GETACL INBOX YYY.YYY.YYY.YYY.00143-XXX.XXX.XXX.XXX.44030: * ACL INBOX owner acdilrsw administrators acdilrsw A37 OK GETACL completed. XXX.XXX.XXX.XXX.44030-YYY.YYY.YYY.YYY.00143: A38 MYRIGHTS INBOX YYY.YYY.YYY.YYY.00143-XXX.XXX.XXX.XXX.44030: * MYRIGHTS INBOX acdilrsw A38 OK MYRIGHTS completed. XXX.XXX.XXX.XXX.44030-YYY.YYY.YYY.YYY.00143: A39 GETQUOTAROOT INBOX YYY.YYY.YYY.YYY.00143-XXX.XXX.XXX.XXX.44030: * QUOTAROOT INBOX ROOT * QUOTA ROOT A39 OK GETQUOTAROOT Ok. The features supported by the server are the following: IMAP4REV1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760191: akonadi-server: After upgrade 1.13.0-1 of akonadi-server, no new mail in IMAP folders is ever read
Package: akonadi-server Version: 1.13.0-1 Severity: grave Justification: renders package unusable Dear Maintainer, After upgrading two jessie machines to newest akonadi (1.13.0) and KDE, as well as libqt4-sql-mysql (4.8.6+git49-gbc62005+dfsg-1), any mails received since the upgrade (2014-08-29 and this morning, respectively) are not seen by kmail. There are no relevant errors in the akonadi error log (note to self: stop trying to use it, it is never going to get better), I cannot give any more details. I suspect the bug is triggered by libqt4-sql-mysql, because checking my last email timestamps would seem to correspond with it (it was pushed later than the other packages), but I have no way to tell for sure. I have the following in a past akonadi server log, but it isn't present in any current one: Control process died, committing suicide! Also, akonadi control log contains the following on both machines, but it seems unrelated: Executable akonadi_nepomuk_feeder for agent akonadi_nepomuk_feeder could not be found! Executable akonadi_folderarchive_agent for agent akonadi_folderarchive_agent could not be found! I manually ran mysql_upgrade on one of the machines, because MySQL was complaining about outdated tables. The other has not displayed any difference in logs. My mysql is version 5.5.37-1 (missing from the report below for some reason). -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (700, 'testing'), (601, 'stable-updates'), (600, 'stable'), (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.1 (SMP w/4 CPU cores) Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages akonadi-server depends on: ii akonadi-backend-mysql 1.13.0-1 ii libakonadiprotocolinternals11.13.0-1 ii libboost-program-options1.55.0 1.55.0+dfsg-2 ii libc6 2.19-9 ii libgcc1 1:4.9.1-4 ii libqt4-dbus 4:4.8.6+git64-g5dc8b2b+dfsg-1 ii libqt4-network 4:4.8.6+git64-g5dc8b2b+dfsg-1 ii libqt4-sql 4:4.8.6+git64-g5dc8b2b+dfsg-1 ii libqt4-xml 4:4.8.6+git64-g5dc8b2b+dfsg-1 ii libqtcore4 4:4.8.6+git64-g5dc8b2b+dfsg-1 ii libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-1 ii libstdc++6 4.9.1-4 akonadi-server recommends no packages. Versions of packages akonadi-server suggests: ii akonadi-backend-mysql 1.13.0-1 pn akonadi-backend-postgresql none pn akonadi-backend-sqlite none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562611:
The reason gpsd doesn't get a fix is that fso-frameworkd interferes with it. As Wilfried Klaebe pointed out, the D-Bus interface is provided by frameworkd. It means that you have the choice between the D-Bus interface and gpsd, you can't use both. (There are patches for frameworkd that allow the use of gpsd, but I haven't tried them). The libgpsd and fso-gpsd in Debian communicate fine at the moment. I manually removed the conflict from the status and available files, and it's working like charm. Another option is to disable ogpsd in frameworkd, use gpsd, and power up the gps at boot. But that increases the power usage in idle mode twice, so it's not a pretty nice solution, but it seems to be the only supported one. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562611:
I don't see why this has been resolved as wontfix. My points: I. There isn't an actual conflict between the packages. They can coexist and work fine on the same system. You can't have the library for a protocol to conflict with a server, just because the server doesn't support the protocol correctly or fully. The two aren't tied to each other, you might run fso-gpsd and gpsd, and connect to gpsd with libgps19, and to fso-gpsd through the D-Bus interface it offers. This works just fine, there is absolutely no conflict between the packages themselves. Besides, they do work together just fine for me, I have a few points on this at the end, but I don't consider them that important. II. fso-gpsd is needed on Neo FreeRunner phones for the following reasons: 1. It manages the GPS power correctly. Modifying the desktop files is not something I'm looking forward to, since I don't like the idea that they will be replaced with my next update. Such a configuration is bound to failure. 2. It provides a D-Bus interface that some people use for scripting. 3. The GPS on this phone isn't working correctly for me with gpsd, it works just fine with fso-gpsd. The problem is that I wait a whole lot until I get a fix. I would have no issue if fso-gpsd wasn't uninstalled by libgps19 for no reason. If fso-gpsd is removed from Debian because it sucks, that's fine, but this conflict is artificial. The package should either be removed completely, or it shouldn't be in a conflict. And about the gpsd compatibility. gpsd is meant to work over a network, and I have used it like that a lot. Which means that the protocol is more or less network protocol, and it should survive a slight difference between the library and the client. A change in the protocol is therefore an issue whether fso- gpsd exists or not, and you can't add conflicts with packages on other systems to avoid the breakage. You can also use a network server that is just as limited and broken as fso-gpsd is. You can't resolve this with a conflict either. fso-gpsd and libgps19 work fine together at the moment, I don't know whether this is by accident or not. fso-gpsd might be broken, but it can be used with this library. A future change in the protocol which might break it might also break network access. If this happens, fso-gpsd would have to be fixed just like the older network machines would have to be upgraded. Placing arbitrary conflicts would do little good. Also, even with a flaky support for the protocol, a server can still be used. I don't know it's not great, but we're all doing it. Maybe libxml2 should have a conflict with Internet Explorer? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571951: python-lightblue: lightblue crashes when trying to connect to OBEX FTP service
Package: python-lightblue
Version: 0.3.2-1+b2
Severity: important
On amd64 architecture, lightblue crashes with a SEGFAULT when trying to connect
to OBEX FTP service. The problem doesn't exist on armel Debian with the
same versions of the packages listed below. It is recent, because it didn't
occur about 2-3 months ago.
I include steps to reproduce through the python console, together with the
backtrace. I replaced the address of the remote device with AA:BB:CC:DD:EE:FF
Python 2.5.5 (r255:77872, Feb 2 2010, 00:25:36)
[GCC 4.4.3] on linux2
Type help, copyright, credits or license for more information.
import lightblue.obex
OBEX_FTP_UUID = '\xf9\xec{\xc4\x95\x11\xd2\x98NRT\x00\xdc\x9e\t'
client = lightblue.obex.OBEXClient(AA:BB:CC:DD:EE:FF, 10)
client.connect({target: OBEX_FTP_UUID})
Program received signal SIGSEGV, Segmentation fault.
PyDict_Next (op=0x0, ppos=0x7fffe098, pkey=0x7fffe0a8,
pvalue=0x7fffe0a0) at ../Objects/dictobject.c:795
795 ../Objects/dictobject.c: Няма такъв файл или директория.
in ../Objects/dictobject.c
(gdb) bt
#0 PyDict_Next (op=0x0, ppos=0x7fffe098, pkey=0x7fffe0a8,
pvalue=0x7fffe0a0) at ../Objects/dictobject.c:795
#1 0x7459d7e9 in lightblueobex_addheaders () from
/usr/lib/pymodules/python2.5/_lightblueobex.so
#2 0x7459b711 in ?? () from
/usr/lib/pymodules/python2.5/_lightblueobex.so
#3 0x0048db18 in call_function (f=0x83f810, throwflag=value optimized
out) at ../Python/ceval.c:3612
#4 PyEval_EvalFrameEx (f=0x83f810, throwflag=value optimized out) at
../Python/ceval.c:2304
#5 0x0048f4e1 in PyEval_EvalCodeEx (co=0x77f86918, globals=value
optimized out, locals=value optimized out,
args=value optimized out, argcount=1414680216, kws=0x7db178, kwcount=0,
defs=0x77f1eba8, defcount=1, closure=0x0)
at ../Python/ceval.c:2875
#6 0x0048def0 in fast_function (f=0x7daff0, throwflag=value optimized
out) at ../Python/ceval.c:3708
#7 call_function (f=0x7daff0, throwflag=value optimized out) at
../Python/ceval.c:3633
#8 PyEval_EvalFrameEx (f=0x7daff0, throwflag=value optimized out) at
../Python/ceval.c:2304
#9 0x0048f4e1 in PyEval_EvalCodeEx (co=0x77f79198, globals=value
optimized out, locals=value optimized out,
args=value optimized out, argcount=1414680216, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0x0)
at ../Python/ceval.c:2875
#10 0x0048f602 in PyEval_EvalCode (co=0x0, globals=0x7fffe098,
locals=0x7fffe0a8) at ../Python/ceval.c:514
#11 0x004ada7c in run_mod (fp=value optimized out, filename=0x4e7696
stdin, flags=0x7fffe730)
at ../Python/pythonrun.c:1273
#12 PyRun_InteractiveOneFlags (fp=value optimized out, filename=0x4e7696
stdin, flags=0x7fffe730)
at ../Python/pythonrun.c:792
#13 0x004adcae in PyRun_InteractiveLoopFlags (fp=0x775366c0,
filename=0x4e7696 stdin, flags=0x7fffe730)
at ../Python/pythonrun.c:723
#14 0x004ae70b in PyRun_AnyFileExFlags (fp=0x775366c0,
filename=0x4e7696 stdin, closeit=0,
flags=0x7fffe730) at ../Python/pythonrun.c:692
#15 0x0041464b in Py_Main (argc=value optimized out, argv=value
optimized out) at ../Modules/main.c:532
#16 0x77206abd in __libc_start_main (main=value optimized out,
argc=value optimized out,
ubp_av=value optimized out, init=value optimized out, fini=value
optimized out, rtld_fini=value optimized out,
stack_end=0x7fffe848) at libc-start.c:222
#17 0x00413a39 in _start ()
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages python-lightblue depends on:
ii libbluetooth3 4.60-1 Library to use the BlueZ Linux Blu
ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib
ii libopenobex1 1.5-2 OBEX protocol library
ii python2.5.4-9An interactive high-level object-o
ii python-support1.0.6.1automated rebuilding support for P
python-lightblue recommends no packages.
python-lightblue suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508652: xserver-xglamo: xglamo crashes randomly when using Qt 4 apps
On Friday 15 May 2009 13:20:33 Luca Capello wrote: forcemerge 508652 508653 user pkg-fso-ma...@lists.alioth.debian.org usertags 508652 + config-xglamo thanks Now that the X.Org Glamo driver has been uploaded to the pkg-fso repository as xserver-xorg-video-glamo, can you try if the bug is still present on an normal X.Org, please? Hello. I believe that my bug report should be marked as invalid. It was my mistake to try running xglamo on Neo1973, which doesn't have the Glamo hardware, so while it is possible that my report was valid, my mistake is much more possible explanation. Such problem doesn't exist on FreeRunner with xserver-xorg-video- glamo, as I just tested. I'm sorry for the false report. Best wishes, Milko Krachounov -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519556: xserver-xorg-input-tslib: Segfault with no RandR support
I've just tried xserver-xorg-input-tslib_0.0.5-8_armel. I'm using it on Neo 1973 (gta01) with fbdev as a video device driver. 1. Without Rotate option, it works perfectly fine, as do 2. With `Option Rotate CCW' it doesn't crash, but the clicks are not handled correctly, as they go to a different point of the screen. Sliding my finger horizontally results in a vertical cursor motion, and vica versa, so it seems that tslib doesn't know that the screen is rotated. The result with 0.0.5-7 is the same for me. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508653: xserver-xglamo: xglamo crashes randomly when using Qt 4 apps
Package: xserver-xglamo Version: 1.3.0.0+git20080807-3 Severity: normal This bug is about xserver-xglamo running on Neo1973 phone. When using xserver-xglamo, X crashes crashes with a segmentation fault during the use of qt4 applications. I couldn't find a series of actions that guarantees reproduction of the bug, but by playing for a minute or two in qtconfig-qt4 by clicking combo boxes, selecting text and going through tabs crashes it every time for me. The backtrace is here: #0 0x0009929c in KdOffscreenAlloc (pScreen=0x227198, size=13456, align=16, locked=0, save=0x8ae44 kaaPixmapSave, privData=0x375678) at ../../../../hw/kdrive/src/koffscreen.c:171 #1 0x0008b1ec in kaaPixmapAllocArea (pPixmap=0x375678) at ../../../../hw/kdrive/src/kaa.c:149 #2 0x0008b34c in kaaMoveInPixmap (pPixmap=0x375678) at ../../../../hw/kdrive/src/kaa.c:188 #3 0x0008b560 in kaaPixmapUseScreen (pPixmap=0x375678) at ../../../../hw/kdrive/src/kaa.c:242 #4 0x0008e4bc in kaaTryDriverSolidFill (pSrc=0x2ac9b0, pDst=0x344028, xSrc=0, ySrc=0, xDst=0, yDst=0, width=115, height=29) at ../../../../hw/kdrive/src/kaapict.c:264 #5 0x0008f7c0 in kaaComposite (op=1 '\001', pSrc=0x2ac9b0, pMask=0x0, pDst=0x344028, xSrc=0, ySrc=0, xMask=115, yMask=29, xDst=0, yDst=0, width=115, height=29) at ../../../../hw/kdrive/src/kaapict.c:556 #6 0x001af21c in damageComposite (op=1 '\001', pSrc=0x2ac9b0, pMask=0x0, pDst=0x344028, xSrc=0, ySrc=0, xMask=115, yMask=29, xDst=0, yDst=0, width=115, height=29) at ../../../miext/damage/damage.c:576 #7 0x00187214 in CompositePicture (op=1 '\001', pSrc=0x2ac9b0, pMask=0x0, pDst=0x344028, xSrc=0, ySrc=0, xMask=115, yMask=29, xDst=0, yDst=0, width=115, height=29) at ../../render/picture.c:1795 #8 0x0018a668 in ProcRenderComposite (client=0x2c3028) at ../../render/render.c:756 #9 0x0018e9f0 in ProcRenderDispatch (client=0x2c3028) at ../../render/render.c:1999 #10 0x001458f8 in XaceCatchExtProc (client=0x2c3028) at ../../Xext/xace.c:299 #11 0x00053624 in Dispatch () at ../../dix/dispatch.c:457 #12 0x00032fac in main (argc=2, argv=0xbefa9ea4, envp=0xbefa9eb0) at ../../dix/main.c:445 -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: armel (armv4tl) Kernel: Linux 2.6.24 (PREEMPT) Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xserver-xglamo depends on: ii libc6 2.7-16 GNU C Library: Shared libraries ii libfontenc1 1:1.0.4-3 X11 font encoding library ii libgcc1 1:4.3.2-1 GCC support library ii libts-0.0-0 1.0-4 touch screen library ii libxau6 1:1.0.3-3 X11 authorisation library ii libxdmcp6 1:1.0.2-3 X11 Display Manager Control Protoc ii libxfont1 1:1.3.3-1 X11 font rasterisation library ii x11-common1:7.3+18 X Window System (X.Org) infrastruc Versions of packages xserver-xglamo recommends: pn xbase-clients none (no description available) ii xfonts-base 1:1.0.0-5 standard fonts for X xserver-xglamo suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
