Bug#1065478: ITP: libnpupnp -- UPnP library, based on Pupnp code, extensively rewritten
Package: wnpp Severity: wishlist Owner: Jean-Francois Dockes X-Debbugs-Cc: debian-de...@lists.debian.org, j...@dockes.org * Package name: libnpupnp Version : 6.1.1 Upstream Contact: Jean-Francois Dockes * URL : https://www.lesbonscomptes.com/upmpdcli * License : BSD Programming Lang: C++ Description : UPnP library, based on Pupnp code, extensively rewritten libnpupnp is a rewrite of the venerable libupnp, with the objective of replacing questionable internal code (XML parser, HTTP server and client) with well maintained external packages (libmicrohttpd, libcurl, expat), also using the C++ STL in place of various locally grown containers, with a goal to improve safety and reliability (reasonably modern C++, no bare pointers etc.). As its predecessor, libupnp, libnpupnp provides developers with an API and open source code for building control points, devices, and bridges that are compliant with Version 1.1 of the Universal Plug and Play Device Architecture Specification - see http://www.upnp.org/ for specifications. libnpupnp is mostly proposed for packaging as a dependency to upmpdcli (separate message), but it can be used by other applications. For example mpd and gerbera can be configured to use it in place of libupnp. Documentation: https://www.lesbonscomptes.com/upmpdcli/npupnp-doc/refdoc/html/index.html Source and existing debian directory: https://framagit.org/medoc92/npupnp Existing packages: https://www.lesbonscomptes.com/upmpdcli/pages/downloads.html#debian Looking for a sponsor.
Bug#1065475: ITP: libupnpp -- Application-oriented C++ layer over the libnpupnp base UPnP library
Package: wnpp Severity: wishlist Owner: Jean-Francois Dockes X-Debbugs-Cc: debian-de...@lists.debian.org, j...@dockes.org * Package name: libupnpp Version : 0.26.3 Upstream Contact: Jean-Francois Dockes * URL : https://www.lesbonscomptes.com/upmpdcli * License : LGPL Programming Lang: C++ Description : Application-oriented C++ layer over the libnpupnp base UPnP library libupnpp wraps libnpupnp calls and data inside easier to use C++ constructs. It can be used to build either devices or control points. It is proposed for packaging as a dependency to upmpdcli (packaging requested in a separate message) Source and current debian directory: https://framagit.org/medoc92/libupnpp Existing packages: https://www.lesbonscomptes.com/upmpdcli/pages/downloads.html#debian Looking for a sponsor.
Bug#1065473: ITP: upmpdcli -- UPnP Media Renderer front-end to MPD, the Music Player Daemon
Package: wnpp Severity: wishlist Owner: Jean-Francois Dockes X-Debbugs-Cc: debian-de...@lists.debian.org, j...@dockes.org * Package name: upmpdcli Version : 1.8.9 Upstream Contact: Jean-Francois Dockes * URL : https://www.lesbonscomptes.com/upmpdcli * License : GPL Programming Lang: C++, Python Description : UPnP Media Renderer front-end to MPD, the Music Player Daemon upmpdcli primarily acts as an UPnP Media Renderer to be controlled with any UPnP controller like, e.g. BubbleUPnP or Kazoo on an Android tablet, or any other UPnP or OpenHome Control Point. It uses an MPD instance to actually play the tracks. A typical configuration might have for example, MPD running on a Raspberry PI, with upmpdcli on the same host or any other Linux PC on the network. The program also has a Media Server function, which can be configured by various plugins to act as a Proxy for external services (streaming or radios) or to serve local audio files. Compared to other UPnP renderers upmpdcli brings the combined renderer/server possibility, and support for OpenHome (local management of the playlist, allowing the control point to go to sleep). upmpdcli already has a Debian package, which I am willing to improve for inclusion in the official repositories, I am in need of a sponsor. The source and debian directory can be found here: https://framagit.org/medoc92/upmpdcli The existing Debian packages are pointed to from there: https://www.lesbonscomptes.com/upmpdcli/pages/downloads.html#debian upmpdcli is already part of audio-oriented, Debian-derived distributions (Moode Audio, Volumio), and is quite widely used to build audio streamers based on small computers. It is also embedded in some hardware streamers. Having it distributed from the default Debian repositories would make things much more convenient for potential users. upmpdcli depends on two additional libraries (libupnpp and libnpupnp), also already packaged, which I will propose for inclusion in separate messages.
Bug#1046946: recoll: Fails to build source after successful build
Hi, This should be fixed by the attached patch or some equivalent in the rules file (delete the generated .qm files when cleaning). recoll-Makefile-am-cleanqm.diff Description: Binary data Lucas Nussbaum writes: > Source: recoll > Version: 1.34.7-1 > Severity: minor > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-sab-20230813 ftbfs-source-after-build > User: debian...@lists.debian.org > Usertags: qa-doublebuild > > Hi, > > This package fails to build a source package after a successful build > (dpkg-buildpackage ; dpkg-buildpackage -S). > > This is probably a clear violation of Debian Policy section 4.9 (clean > target), > but this is filed as severity:minor for now, because a discussion on > debian-devel showed that we might want to revisit the requirement of a > working > 'clean' target. > > More information about this class of issues, included common problems and > solutions, is available at > https://wiki.debian.org/qa.debian.org/FTBFS/SourceAfterBuild > > Relevant part of the build log: > > cd /<> && runuser -u user42 -- dpkg-buildpackage > > --sanitize-env -us -uc -rfakeroot -S > > > > > > dpkg-buildpackage: info: source package recoll > > dpkg-buildpackage: info: source version 1.34.7-1 > > dpkg-buildpackage: info: source distribution unstable > > dpkg-buildpackage: info: source changed by Kartik Mistry > > > > dpkg-source --before-build . > > debian/rules clean > > dh clean --with python3 > >dh_auto_clean > >make -j8 distclean > > make[1]: Entering directory '/<>' > > Making distclean in . > > make[2]: Entering directory '/<>' > > rm -f recollindex recollq xadump > > test -z "librecoll.la" || rm -f librecoll.la > > rm -rf .libs _libs > > rm -f python/recoll/*.pyc > > rm -f *.o > > rm -rf python/pychm/build > > rm -f ./so_locations > > rm -f aspell/*.o > > rm -rf aspell/.libs aspell/_libs > > rm -rf python/pychm/recollchm.egg-info > > rm -f aspell/*.lo > > rm -rf bincimapmime/.libs bincimapmime/_libs > > rm -rf python/pychm/setup.py > > rm -f bincimapmime/*.o > > rm -rf common/.libs common/_libs > > rm -rf python/recoll/Recoll.egg-info > > rm -f bincimapmime/*.lo > > rm -f *.lo > > rm -rf python/recoll/__pycache__ > > rm -f common/*.o > > rm -rf index/.libs index/_libs > > rm -rf python/recoll/build > > rm -f common/*.lo > > rm -rf internfile/.libs internfile/_libs > > rm -f index/*.o > > rm -f *.tab.c > > test -z "python/recoll/setup.py python/pychm/setup.py > > python/pyaspell/setup.py" || rm -f python/recoll/setup.py > > python/pychm/setup.py python/pyaspell/setup.py > > rm -rf query/.libs query/_libs > > rm -f index/*.lo > > test . = "." || test -z "" || rm -f > > rm -f internfile/*.o > > rm -f aspell/.deps/.dirstamp > > rm -rf rcldb/.libs rcldb/_libs > > rm -f internfile/*.lo > > rm -f aspell/.dirstamp > > rm -f query/*.o > > rm -f bincimapmime/.deps/.dirstamp > > rm -rf unac/.libs unac/_libs > > rm -f query/*.lo > > rm -f bincimapmime/.dirstamp > > rm -rf utils/.libs utils/_libs > > rm -f rcldb/*.o > > rm -f common/.deps/.dirstamp > > rm -f common/autoconfig.h common/stamp-h1 > > rm -f rcldb/*.lo > > rm -f common/.dirstamp > > rm -f unac/*.o > > rm -f index/.deps/.dirstamp > > rm -f unac/*.lo > > rm -f index/.dirstamp > > rm -f utils/*.o > > rm -f internfile/.deps/.dirstamp > > rm -f libtool config.lt > > rm -f utils/*.lo > > rm -f internfile/.dirstamp > > rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags > > rm -f query/.deps/.dirstamp > > rm -f cscope.out cscope.in.out cscope.po.out cscope.files > > rm -f query/.dirstamp > > rm -rf python/pychm/build > > rm -f rcldb/.deps/.dirstamp > > rm -rf python/pychm/dist/* > > rm -f rcldb/.dirstamp > > rm -rf python/pyaspell/build > > rm -f unac/.deps/.dirstamp > > rm -rf python/pyaspell/dist/* > > rm -f unac/.dirstamp > > make -C qtgui clean > > rm -f utils/.deps/.dirstamp > > rm -f utils/.dirstamp > > make[3]: Entering directory '/<>/qtgui' > > rm -f qrc_recoll.cpp > > rm -f .moc/moc_predefs.h > > rm -f .moc/moc_actsearch_w.cpp .moc/moc_advsearch_w.cpp > > .moc/moc_confgui.cpp .moc/moc_confguiindex.cpp .moc/moc_firstidx.cpp > > .moc/moc_fragbuts.cpp .moc/moc_idxmodel.cpp .moc/moc_idxsched.cpp > > .moc/moc_preview_load.cpp .moc/moc_preview_plaintorich.cpp > > .moc/moc_preview_w.cpp .moc/moc_ptrans_w.cpp .moc/moc_rclhelp.cpp > > .moc/moc_rclmain_w.cpp .moc/moc_reslist.cpp .moc/moc_restable.cpp > > .moc/moc_scbase.cpp .moc/moc_searchclause_w.cpp .moc/moc_snippets_w.cpp > > .moc/moc_specialindex.cpp .moc/moc_spell_w.cpp .moc/moc_ssearch_w.cpp > > .moc/moc_systray.cpp .moc/moc_uiprefs_w.cpp .moc/moc_viewaction_w.cpp > > .moc/moc_webcache.cpp .moc/moc_editdialog.cpp .moc/moc_listdialog.cpp > > .moc/moc_qxtconfirmationmessage.cpp .moc/moc_crontool.cpp > >
Bug#930281: Fixed?
Hi, Yes, the fix has been in recoll versions for quite some time. jf Kartik Mistry writes: > Hi, > > Just wanted to check if this bug[1] is fixed in the latest version of > recoll? If yes, we can close it. > > Thanks! > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930281 > > -- > Kartik Mistry | કાર્તિક મિસ્ત્રી > kartikm.wordpress.com >
Bug#985075: recoll: Please provide recoll 1.29.1
I think that you need to use the sources file for the bullseye package from lesbonscomptes, not buster: deb11-64$ apt-cache policy recoll recoll: Installed: 1.29.1-1~ppa1~bullseye Candidate: 1.29.1-1~ppa1~bullseye Version table: *** 1.29.1-1~ppa1~bullseye 500 500 http://www.lesbonscomptes.com/upmpdcli/downloads/debian bullseye/main amd64 Packages 100 /var/lib/dpkg/status 1.28.5-1 500 500 http://deb.debian.org/debian bullseye/main amd64 Packages It seems to work fine on my bullseye/sid copy. deb11-64$ echo 'from recoll import recoll;db=recoll.connect()' | python3 :3:common/rclinit.cpp:387::Recoll 1.29.1 + Xapian 1.4.18 [/home/dockes/.recoll] J.F. Dockes Eric Valette writes: > On 3/12/21 6:38 PM, Jean-Francois Dockes wrote: > > > > Hi, > > > > Just a comment: I think that upmpdcli-uprcl works fine with either > > recoll 1.28 or 1.29, and it's the only upmpdcli component which needs > > recoll. I'm not sure why there would be a conflict ? > > because the .deb from your repository (non official debian) > python-recoll is for python < 3.8 whereas unstable is now at 3.9. Also > reacll in debian is at 1.28.5 but chnaged to 1.29.1 in debian. > > So I cannot upgrade python-recoll and some part of upmpdcli depend on it > > apt-cache policy recoll > recoll: >Installé : 1.28.5-1 >Candidat : 1.29.1-1~ppa1~buster > Table de version : > 1.29.1-1~ppa1~buster 500 > 500 http://www.lesbonscomptes.com/upmpdcli/downloads/debian > buster/main amd64 Packages > *** 1.28.5-1 500 > 500 http://ftp.fr.debian.org/debian unstable/main amd64 Packages > 100 /var/lib/dpkg/status > apt-get -s install recoll python-recoll python3-recoll > NOTE: Ceci n'est qu'une simulation ! >apt-get a besoin des privilèges du superutilisateur >pour pouvoir vraiment fonctionner. >Veuillez aussi noter que le verrouillage est désactivé, >et la situation n'est donc pas forcément représentative >de la réalité ! > Lecture des listes de paquets... Fait > Construction de l'arbre des dépendances... Fait > Lecture des informations d'état... Fait > Certains paquets ne peuvent être installés. Ceci peut signifier > que vous avez demandé l'impossible, ou bien, si vous utilisez > la distribution unstable, que certains paquets n'ont pas encore > été créés ou ne sont pas sortis d'Incoming. > L'information suivante devrait vous aider à résoudre la situation : > > Les paquets suivants contiennent des dépendances non satisfaites : > dh-python : Casse: python > python3-recoll : Dépend: python3 (< 3.8) mais 3.9.2-2 devra être installé > E: Erreur, pkgProblem::Resolve a généré des ruptures, ce qui a pu être > causé par les paquets devant être gardés en l'état. > > > > -- eric >
Bug#985075: recoll: Please provide recoll 1.29.1
Hi, Just a comment: I think that upmpdcli-uprcl works fine with either recoll 1.28 or 1.29, and it's the only upmpdcli component which needs recoll. I'm not sure why there would be a conflict ? J.F. Dockes Eric Valette writes: > Package: recoll > Version: 1.28.5-1 > Severity: wishlist > > Recoll 1.29.1 has been released. I have some package (upmpdcli) that > conflicts. > > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.10.21 (SMP w/8 CPU threads; PREEMPT) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE > Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages recoll depends on: > ii recollcmd 1.28.5-1 > ii recollgui 1.28.5-1 > > recoll recommends no packages. > > recoll suggests no packages. > > -- no debconf information >
Bug#975037: recoll: watchfile broken
The url is now: https://www.lesbonscomptes.com/recoll/pages/download.html instead of https://www.lesbonscomptes.com/recoll/download.html J.F. Tobias Frost writes: > Package: recoll > Severity: normal > > Dear Maintainer, > > tracker.d.o says "404" on the watch file, so it seems to be broken… > > > -- > tobi
Bug#950782: Acknowledgement (Please support 7z archives by adding python3-lz4 to Suggests)
Hi, You need pylzma: https://pypi.org/project/pylzma/ I don't think that it's packaged by Debian though, you will have to use pip3 or such. jf Marcus Frings writes: > Dear maintainer, > > I wrote: > > > Recoll supports indexing 7z archives. If python3-lz4 is not installed, > > recoll gives errors such as > > > > :2:utils/netcon.cpp:699::NetconData::send: send(16): errno 32: Broken > > pipe :2:utils/execmd.cpp:874::ExecCmd::send: send failed > > :2:internfile/mh_execm.cpp:209::MHExecMultiple: send error > > :2:internfile/internfile.cpp:797::FileInterner::internfile: > > next_document error [not-disclosed-here.7z] > > application/x-7z-compressed > > Unfortunately, recoll still reports the same error some days after I > installed python3-lz4, so it was no solution at all. I am sorry that I > suggested something that does not work. > > Best regards, > Marcus > x[DELETED ATTACHMENT , application/pgp-signature]
Bug#817157: recoll: index corruption in version 1.17.3-2
Kartik Mistry writes: > Package: recoll > > Hi, > > Is this still happening with latest recoll and xapian (Since #808610 > is done long time ago!)? > > Thanks! I think that this was an old Xapian issue, and that it can be closed. jf
Bug#935709: libupnp13: Port autoconfiguration does not work when running multiple instances of the library
Package: libupnp13 Version: 1:1.8.4-2 Severity: important Dear Maintainer, When libupnp is configured with --enable-reuseaddr (the case on Debian), it does not retry with a higher port if the default one (49152) is busy. This makes it difficult to run multiple apps (e.g. renderer + control point or multiple control points) on the same host. The second libupnp-based application fails if it tries to use the default port. The only workaround is to manually configure different ports, but this is a major regression compared to the previous situation (libupnp 1.6) where the next available port was just used. See github issue 91, which includes a patch (also available in 1.8.5). https://github.com/mrjimenez/pupnp/issues/91 Cheers, J.F. Dockes -- System Information: Debian Release: 10.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/3 CPU cores) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libupnp13 depends on: ii libc6 2.28-10 ii libixml10 1:1.8.4-2 libupnp13 recommends no packages. libupnp13 suggests no packages. -- no debconf information
Bug#930281: PDF which fails to index with TypeError: object of type 'NoneType' has no len()
Thanks, it's nice to see the Recoll metadata gathering facilities being put to use :) jf
Bug#930281: PDF which fails to index with TypeError: object of type 'NoneType' has no len()
Hi, The document has XMP metadata inside XML attributes, instead of element text. The script did not handle this well, and there were a few other issues too. I am attaching a fixed script for your testing, it should replace /usr/share/recoll/rclpdf.py J.F. Dockes rclpdf.py Description: Binary data
Bug#925884: recoll: pstotext does not work any longer
Hi, This is fixed in current recoll code. The current handler is fully compatible with recoll 1.24: https://opensourceprojects.eu/p/recoll1/code/ci/2f75550348a06bfd354df241b3ea0f61a45c102c/tree/src/filters/rclps The fixed handler uses ps2pdf and pdftotext. The output is much better than ps2ascii, and ps2pdf extracts some metadata from the postscript comments (e.g.: %%Title:) J.F. Dockes zieg...@uni-freiburg.de writes: > Package: recoll > Version: 1.24.3-3 > Severity: normal > Tags: upstream > > Dear Maintainer, > > recollindex does not longer work for *.ps files. > It works, if /usr/bin/pstotext is linked to /usr/bin/ps2ascii. > > pstotext seems to be broken. It was removed from Debian testing. One > should replace it in rclps and rcldvi by something else. > > -- System Information: > Debian Release: buster/sid > Architecture: amd64 (x86_64) > > Kernel: Linux 5.0.4-00377-g1e1663533ef5 (SMP w/4 CPU cores) > Kernel taint flags: TAINT_USER > Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE=de_DE > (charmap=ISO-8859-1) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages recoll depends on: > ii recollcmd 1.24.3-3 > ii recollgui 1.24.3-3 > > recoll recommends no packages. > > recoll suggests no packages. > > -- no debconf information > >
Bug#906764: recoll: FTBFS in buster/sid (invalid use of incomplete type 'class QAbstractItemView')
The attached patch should clear the problem. jf recoll-qabstractviewitem.diff Description: Binary data
Bug#895301: python-chm: Python3 port needed and available
Package: python-chm Version: 0.8.4.1-1 Severity: normal Tags: newcomer patch upstream Dear Maintainer, pychm has not been ported to Python3 by its author. The project on Github is at least sleepy (last commit 3 years ago). I submitted a pull request for a Python3 patch with no response. I would propose that the patch be used to generate a new version of the package, compatible with python2 and 3. My motivation for this is that I am using pychm for extracting text from chm files for Recoll, which is moving to full Python3 compatibility. https://github.com/dottedmag/pychm/pull/5 Most of the volume of changes in the patch is in the generated files, and due to the change of Swig version. The "manual" changes are reasonably limited and straightforward. jf -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-chm depends on: ii libc62.24-11+deb9u3 ii libchm1 2:0.40a-3+b2 ii python 2.7.13-2 python-chm recommends no packages. python-chm suggests no packages. -- no debconf information
Bug#886899: recoll: epub-filter broken, requires 'python-epub' which is not packaged
As an aside to this, catdoc is not needed at all by recent recoll versions (1.19.12 and later). Details about the external programs here: https://www.lesbonscomptes.com/recoll/features.html#doctypes jf (upstream)
Bug#880310: recoll: FTBFS: configure: error: qmake seems to be using Qt version 3 which is not supported any more
Lucas Nussbaum writes:
> Source: recoll
> Version: 1.23.2-1
> Severity: serious
> Tags: buster sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20171030 qa-ftbfs
> Justification: FTBFS on amd64
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
>
> Relevant part (hopefully):
> > checking for pthread_create in -lpthread... yes
> > checking for dlopen in -ldl... yes
> > checking for zlibVersion in -lz... yes
> > checking for type of inbuf parameter to iconv... checking for type of
> > string parameter to putenv... checking for xapian-config...
> > /usr/bin/xapian-config
> > checking for qmake... /usr/bin/qmake
> > configure: error: qmake seems to be using Qt version 3 which is not
> > supported any more
> > debian/rules:28: recipe for target 'config.status' failed
>
> The full build log is available from:
>http://aws-logs.debian.net/2017/10/30/recoll_1.23.2-1_unstable.log
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.
This seems to work fine for me (Build log on my Debian unstable VM follows).
The message about qt 3 is misleading, I'll change it. The part which fails
is the following:
# Check Qt version
qmakevers="`${QMAKE} --version 2>&1`"
#echo "qmake version: $qmakevers"
v4=`expr "$qmakevers" : '.*Qt[ ][ ]*version[ ][ ]*4.*'`
v5=`expr "$qmakevers" : '.*Qt[ ][ ]*version[ ][ ]*5.*'`
if test X$v4 = X0 -a X$v5 = X0; then
AC_MSG_ERROR([qmake seems to be using Qt version 3 which is not supported
any more])
else
if test X$v4 != X0 ; then
AC_MSG_NOTICE([using qt version 4 user interface])
else
AC_MSG_NOTICE([using qt version 5 user interface])
fi
QTGUI=qtgui
fi
Have you got a way to print the output from:
/usr/bin/qmake --version
in your build environment ?
Jf
deb-sid-64$ cat /etc/debian_version
buster/sid
deb-sid-64$ cat /etc/apt/sources.list
deb http://debian.proxad.net/debian/ unstable main
deb-src http://debian.proxad.net/debian/ unstable main
deb-sid-64$ sudo apt update
Hit:1 http://debian.proxad.net/debian unstable InRelease
Hit:2 http://www.lesbonscomptes.com/upmpdcli/downloads/debian stretch InRelease
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
deb-sid-64$ sudo apt dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
deb-sid-64$ mkdir rclsrc
deb-sid-64$ cd rclsrc/
deb-sid-64$ apt-get source recoll
Reading package lists... Done
NOTICE: 'recoll' packaging is maintained in the 'Git' version control system at:
https://anonscm.debian.org/cgit/collab-maint/recoll.git
Please use:
git clone https://anonscm.debian.org/cgit/collab-maint/recoll.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 2559 kB of source archives.
Get:1 http://debian.proxad.net/debian unstable/main recoll 1.23.2-1 (dsc) [2132
B]
Get:2 http://debian.proxad.net/debian unstable/main recoll 1.23.2-1 (tar) [2547
kB]
Get:3 http://debian.proxad.net/debian unstable/main recoll 1.23.2-1 (diff)
[9680 B]
Fetched 2559 kB in 4s (534 kB/s)
dpkg-source: info: extracting recoll in recoll-1.23.2
dpkg-source: info: unpacking recoll_1.23.2.orig.tar.gz
dpkg-source: info: unpacking recoll_1.23.2-1.debian.tar.xz
deb-sid-64$ cd recoll-1.23.2/
deb-sid-64$ debuild
dpkg-buildpackage -rfakeroot -us -uc -ui
dpkg-buildpackage: info: source package recoll
dpkg-buildpackage: info: source version 1.23.2-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Kartik Mistry
dpkg-source --before-build recoll-1.23.2
dpkg-buildpackage: info: host architecture amd64
fakeroot debian/rules clean
dh_testdir
dh_testroot
rm -f build-stamp config.log
[ ! -f Makefile ] || /usr/bin/make distclean
dh_clean Makefile
dpkg-source -b recoll-1.23.2
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building recoll using existing ./recoll_1.23.2.orig.tar.gz
dpkg-source: warning: ignoring deletion of file filters/#rclpdf.py#, use
--include-removal to override
dpkg-source: info: building recoll in recoll_1.23.2-1.debian.tar.xz
dpkg-source: info: building recoll in recoll_1.23.2-1.dsc
debian/rules build
dh_testdir
./configure CFLAGS="-g -O2
-fdebug-prefix-map=/home/dockes/rclsrc/recoll-1.23.2=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -O2"
LDFLAGS="-Wl,-z,relro" \
Bug#856605: recoll does not index the new Libreoffice file format in flat plain xml: FODPT, FODP, etc
Martin Monperrus writes: > Package: recoll > Version: 1.22.4-1 > Severity: normal > > Dear Maintainer, > > recoll does not index the new Libreoffice file formats: FODPT, FODP, > etc. (flat plain xml files, usable with Git) > > Some changes in mimemap, mimeconf and mimeview are required to handle those > files. This is implemented in the just released recoll 1.23.0, or the attached patch can add the capability to recoll 1.22.4 The patch adds an input handler program and a few lines to mimemap and mimeconf. Cheers, jf recoll-odf-flat-xml.diff Description: Binary data
Bug#849705: unrtf: Stack buffer overflow
Willi Mann writes:
> Hi Dave,
> Hi Jean-Francois,
>
> I got the following bug report, apparrently describing a buffer overflow
> in unrtf - which I can reproduce. Do you have a suggestion for a fix?
>
> I'm also CCing debian's security team.
>
> WM
I guess that you can just add a package patch to increate the str[] buffer
size, something like
- char str[10];
+ char str[15];
(I'm sure that you could get by with less than 15 but I don't see the
point).
For completeness, sprintf() could be changed to snprintf(), but maybe this
can be left for the next release?
attr_push() does an strdup of the 2nd parameter, so the increased size
should not be an issue there.
I've not tested the change, but I'm foolishly confident that it should fix the
issue. I'll give it a better look in the following days (and also look for
possible other instances of the problem).
jf
> Am 2016-12-30 um 01:44 schrieb Skylake:
> > Package: unrtf
> > Version: 0.21.9-clean-2
> >
> > I've found a Stack-based buffer overflow in unrtf 0.21.9, which affects
> > three
> > functions including: cmd_expand, cmd_emboss and cmd_engrave.
> >
> > # convert.c
> >
> > static int
> > cmd_expand (Word *w, int align, char has_param, int param) {
> > char str[10];
> > if (has_param) {
> > sprintf(str, "%d", param/4); // Overflow, 9-digit negative value
> > triggers the bug
> > if (!param)
> > attr_pop(ATTR_EXPAND);
> > else
> > attr_push(ATTR_EXPAND, str);
> > }
> > return FALSE;
> > }
> >
> > Apparently writing a negative integer to the buffer can trigger the
> > overflow
> > (Minus sign needs an extra byte).
> >
> > * How to trigger the bug *
> >
> > $ echo "\expnd-4" > poc
> > $ unrtf poc
> >
> >
> >
> >
> >
> >
> > *** buffer overflow detected ***: unrtf terminated
> > === Backtrace: =
> > /lib/i386-linux-gnu/libc.so.6(+0x6737a)[0xb764f37a]
> > /lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x37)[0xb76dfe07]
> > /lib/i386-linux-gnu/libc.so.6(+0xf60a8)[0xb76de0a8]
> > /lib/i386-linux-gnu/libc.so.6(+0xf58b8)[0xb76dd8b8]
> > /lib/i386-linux-gnu/libc.so.6(_IO_default_xsputn+0xa6)[0xb7653bf6]
> > /lib/i386-linux-gnu/libc.so.6(_IO_vfprintf+0xf66)[0xb762b1d6]
> > /lib/i386-linux-gnu/libc.so.6(__vsprintf_chk+0x90)[0xb76dd950]
> > /lib/i386-linux-gnu/libc.so.6(__sprintf_chk+0x20)[0xb76dd8a0]
> > unrtf[0x804c7b8]
> > unrtf[0x804f77d]
> > unrtf[0x804f9e7]
> > unrtf[0x804920b]
> > /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf6)[0xb7600276]
> > unrtf[0x804953c]
> > === Memory map:
> > 08048000-0805b000 r-xp 08:01 405354 /usr/bin/unrtf
> > 0805b000-0805c000 r--p 00012000 08:01 405354 /usr/bin/unrtf
> > 0805c000-0805d000 rw-p 00013000 08:01 405354 /usr/bin/unrtf
> > 0805d000-08085000 rw-p 00:00 0
> > 0952d000-0954e000 rw-p 00:00 0 [heap]
> > b75ca000-b75e6000 r-xp 08:01 393233
> > /usr/lib/i386-linux-gnu/libgcc_s.so.1
> > b75e6000-b75e7000 r--p 0001b000 08:01 393233
> > /usr/lib/i386-linux-gnu/libgcc_s.so.1
> > b75e7000-b75e8000 rw-p 0001c000 08:01 393233
> > /usr/lib/i386-linux-gnu/libgcc_s.so.1
> > b75e8000-b7799000 r-xp 08:01 395818
> > /usr/lib/i386-linux-gnu/libc-2.24.so
> > b7799000-b779b000 r--p 001b 08:01 395818
> > /usr/lib/i386-linux-gnu/libc-2.24.so
> > b779b000-b779c000 rw-p 001b2000 08:01 395818
> > /usr/lib/i386-linux-gnu/libc-2.24.so
> > b779c000-b779f000 rw-p 00:00 0
> > b77a3000-b77a6000 rw-p 00:00 0
> > b77a6000-b77a8000 r--p 00:00 0 [vvar]
> > b77a8000-b77aa000 r-xp 00:00 0 [vdso]
> > b77aa000-b77cc000 r-xp 08:01 393914
> > /usr/lib/i386-linux-gnu/ld-2.24.so
> > b77cc000-b77cd000 rw-p 00:00 0
> > b77cd000-b77ce000 r--p 00022000 08:01 393914
> > /usr/lib/i386-linux-gnu/ld-2.24.so
> > b77ce000-b77cf000 rw-p 00023000 08:01 393914
> > /usr/lib/i386-linux-gnu/ld-2.24.so
> > bf992000-bf9b3000 rw-p 00:00 0 [stack]
> > Aborted
> >
> > * Test environment *
> >
> > Linux debian 4.7.0-1-686-pae #1 SMP Debian 4.7.8-1 (2016-10-19) i686
> > GNU/Linux
> > libc6 2.24-8
> >
> > Regards,
> > Amir
> >
> > Sent with ProtonMail Secure Email.
> >
>
>
Bug#846211: dpkg-dev: dpkg-shlibdeps execs objdump on wrong lib architecture
Guillem Jover writes: > Control: tags -1 moreinfo > Control: severity -1 normal > > Hi! > > On Tue, 2016-11-29 at 03:19:31 -0700, Jean-Francois Dockes wrote: > > Package: dpkg-dev > > Version: 1.17.27 > > Severity: important > > > This happens on an odrobian hybrid installation: 64 bits kernel with > > 32 bits userland. gcc -v says: > > > > Using built-in specs. > > COLLECT_GCC=/usr/bin/gcc-4.9.real > > COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.9/lto-wrapper > > Target: arm-linux-gnueabihf > > > > debuild fails with the following output: > > > > dh_shlibdeps -O--parallel > > objdump: /lib/aarch64-linux-gnu/libpthread.so.0: File format not recognized > > dpkg-shlibdeps: error: objdump gave error exit status 1 > > dh_shlibdeps: dpkg-shlibdeps -Tdebian/libupnp6.substvars > > debian/libupnp6/usr/lib/arm-linux-gnueabihf/libthreadutil.so.6.0.4 ... > > returned exit code 1 > > debian/rules:14: recipe for target 'binary' failed > > > > > > Workaround: Just forbidding (chmod 0) access to > > /lib/aarch64-linux-gnu/ and /usr/lib/aarch64-linux-gnu/ fixes the > > problem (the package build succeeds, the packages are ok), so it would > > appear that someone is looking in the wrong places. > > It seems to me you are trying to cross-compile but are not passing the > correct arguments to dpkg-buildpackage? Giving more detail would help, > build logs, the way you invoked dpkg-buildpackage. What are the host > architecture you are trying to build for, etc. Hi, I am not trying to cross-compile (this is the whole point of using this sytem actually: a reasonably fast native ARM system to build things). The userland is ARM 32 bits: the gcc ouput above is the one from the normal system compiler. ARM64 is present on the system as a foreign architecture, and just used for a few commands, specific to building system images as far as I can see. dpkg-buildpackage is invoked from debuild, which in turn invokes dh_shlibdebs. I am copying a full buildlog at the end (I cut out most of the CC lines, as just bit repetitive and boring...). Setting DEB_BUILD_ARCH=armv7l works for raw dpkg-buildpackages (as an alternative to forbidding access to the aarch64 dirs), but not for debuild (for which the directory interdiction works). The system I am using is described in the following link, I think that looking there will be better than my bad paraphrasing of the same information: http://forum.odroid.com/viewtopic.php?t=18771 Look for the 'Linux Hybrid Kernel64/Debian32' section. Contents of the 64 bits part: odroid32$ sudo ls /usr/lib/aarch64-linux-gnu/ audit gconv odroid32$ sudo ls /lib/aarch64-linux-gnu/ ld-2.19.so libanl.so.1 libcrypt.so.1 libmemusage.so libnss_dns.so.2libnss_nis.so.2 libresolv-2.19.so libutil-2.19.so ld-linux-aarch64.so.1libc-2.19.so libdl-2.19.so libnsl-2.19.so libnss_files-2.19.so libnss_nisplus-2.19.so libresolv.so.2 libutil.so.1 libBrokenLocale-2.19.so libc.so.6 libdl.so.2 libnsl.so.1 libnss_files.so.2 libnss_nisplus.so.2 librt-2.19.so libBrokenLocale.so.1 libcidn-2.19.so libgcc_s.so.1 libnss_compat-2.19.so libnss_hesiod-2.19.so libpcprofile.so librt.so.1 libSegFault.so libcidn.so.1 libm-2.19.so libnss_compat.so.2 libnss_hesiod.so.2 libpthread-2.19.so libthread_db-1.0.so libanl-2.19.so libcrypt-2.19.so libm.so.6 libnss_dns-2.19.so libnss_nis-2.19.so libpthread.so.0 libthread_db.so.1 odroid32$ file /usr/bin/* | grep 'ELF 64' /usr/bin/fw_printenv: ELF 64-bit LSB executable, ARM aarch64... /usr/bin/kwboot: ELF 64-bit LSB executable, ARM aarch64... /usr/bin/mkimage: ELF 64-bit LSB executable, ARM aarch64... /usr/bin/mksunxiboot: ELF 64-bit LSB executable, ARM aarch64... # (that's all) Nothing much as you can see, and interdicting access to the directories leaves the system normally usable for a non-root user. Some 32bit bits: odroid32$ ls /lib/arm-linux-gnueabihf/ | wc 146 146 2418 odroid32$ ls /usr/lib/arm-linux-gnueabihf/ | wc 913 913 15206 odroid32$ file /usr/bin/* | grep 'ELF 32' | wc -l 409 odroid32$ ldd /bin/ls libselinux.so.1 => /lib/arm-linux-gnueabihf/libselinux.so.1 (0xf7304000) libacl.so.1 => /lib/arm-linux-gnueabihf/libacl.so.1 (0xf72ed000) libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xf71fd000) /lib/ld-linux-armhf.so.3 (0xaaaff000) libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0xf71a1000) libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xf718e000) libattr.so.1 => /lib/
Bug#846211: dpkg-dev: dpkg-shlibdeps execs objdump on wrong lib architecture
Package: dpkg-dev Version: 1.17.27 Severity: important Dear Maintainer, This happens on an odrobian hybrid installation: 64 bits kernel with 32 bits userland. gcc -v says: Using built-in specs. COLLECT_GCC=/usr/bin/gcc-4.9.real COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.9/lto-wrapper Target: arm-linux-gnueabihf debuild fails with the following output: dh_shlibdeps -O--parallel objdump: /lib/aarch64-linux-gnu/libpthread.so.0: File format not recognized dpkg-shlibdeps: error: objdump gave error exit status 1 dh_shlibdeps: dpkg-shlibdeps -Tdebian/libupnp6.substvars debian/libupnp6/usr/lib/arm-linux-gnueabihf/libthreadutil.so.6.0.4 ... returned exit code 1 debian/rules:14: recipe for target 'binary' failed Workaround: Just forbidding (chmod 0) access to /lib/aarch64-linux-gnu/ and /usr/lib/aarch64-linux-gnu/ fixes the problem (the package build succeeds, the packages are ok), so it would appear that someone is looking in the wrong places. -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: armhf (aarch64) Foreign Architectures: arm64 Kernel: Linux 3.14.29-14-odrobian+ (SMP w/4 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dpkg-dev depends on: ii base-files8+deb8u6 ii binutils 2.25-5 ii bzip2 1.0.6-7+b3 ii libdpkg-perl 1.17.27 ii make 4.0-8.1 ii patch 2.7.5-1 ii xz-utils 5.1.1alpha+20120614-2+b3 Versions of packages dpkg-dev recommends: ii build-essential 11.7 ii fakeroot 1.20.2-1 ii gcc [c-compiler] 4:4.9.2-2 ii gcc-4.9 [c-compiler] 4.9.2-10 ii gnupg1.4.18-7+deb8u3 ii gpgv 1.4.18-7+deb8u3 ii libalgorithm-merge-perl 0.08-2 Versions of packages dpkg-dev suggests: ii debian-keyring 2015.04.10 -- no debconf information
Bug#836764: recoll: default mimemap is confusing
Martin Monperrus writes: > Dear Jean-François, > > I'd be curious to know how you hit this problem with these file types which > > usually have proper extensions ? > I wanted to only index some file types in order to reduce the index size > (which was 16GB!). The only relevant option I found was > "indexedmimetypes". I added the "file -i" types in "indexedmimetypes", > yet nothing was indexed! It was then quite hard to debug. Thanks, I understand. I'll add a note to the documentation. jf
Bug#836764: recoll: default mimemap is confusing
Martin Monperrus writes: > Package: recoll > Version: 1.22.3-1 > Severity: normal > > I've just spent a long time to understand why my indexing configuration > fails. > > I've finally realized that the cause is that the mimetypes defined in mimemap > are different from the ones returned by 'file -i'. > > Example: > text/x-text (file) vs application/x-tex (mimemap) > application/vnd.oasis.opendocument.text (file) vs > application/vnd.sun.xml.writer (mimemap) > > For sake of least astonishment, they could be aligned. Some of the mimemap values are obsolete, but changing them would more or less force every Recoll user to reset their index, so it will only happen in conjunction with another change which would force a reindex. This is more an upstream issue than one specific to the Debian package actually. I am taking a note of the issue, and the values can be fixed at the next occasion. I'd be curious to know how you hit this problem with these file types which usually have proper extensions ? J.F. Dockes
Bug#784523: Bumping severities
Lisandro Damián Nicanor Pérez Meyer writes: > Control: tag -1 patch > > On Friday 22 January 2016 17:20:28 Jean-Francois Dockes wrote: > [snip] > > Hi, > > > > As far as I know, Recoll builds fine with qt5-webkit > 5.2. Just get rid of > > the QMAKE=qmake-qt4 line in the rules. > > Indeed, this is true. Thanks Jean-Francois! > > I'm attaching a patch to get this done. > > I have seen that the latest upload was a NMU agreed with you, please take a > look at the patch and tell me if you want me to upload it. > > Thanks in advance! Hi, Last week's upload was validated by Kartik Mistry, who is the Debian package maintainer. I'm the upstream and I see nothing wrong with the patch, but Kartik should probably be in the loop if he is around. Cheers, jf > -- > No pienses que estoy loco, es sólo una manera de actuar > De mí - Charly García > > Lisandro Damián Nicanor Pérez Meyer > http://perezmeyer.com.ar/ > http://perezmeyer.blogspot.com/ > > -- > diff --git a/debian/changelog b/debian/changelog > index 1958191..4537a22 100644 > --- a/debian/changelog > +++ b/debian/changelog > @@ -1,3 +1,10 @@ > +recoll (1.21.0-1.2) UNRELEASED; urgency=medium > + > + * Non-maintainer upload. > + * Switch to Qt 5 (Closes: #784523). > + > + -- Lisandro Damián Nicanor Pérez Meyer <lisan...@debian.org> Fri, 22 Jan > 2016 13:29:02 -0300 > + > recoll (1.21.0-1.1) unstable; urgency=medium > >* Non-maintainer upload (agreed by maintainer). (Closes: #809478) > diff --git a/debian/control b/debian/control > index 368f55a..973c6c8 100644 > --- a/debian/control > +++ b/debian/control > @@ -7,8 +7,8 @@ Build-Depends: autotools-dev, > debhelper (>= 7), > dh-python, > dpkg-dev (>= 1.16.1~), > - libqt4-dev, > - libqtwebkit-dev, > + qtbase5-dev, > + libqt5webkit5-dev, > libx11-dev, > libxapian-dev (>= 1.2.0), > libz-dev, > diff --git a/debian/rules b/debian/rules > index 82590ae..2389a87 100755 > --- a/debian/rules > +++ b/debian/rules > @@ -17,8 +17,8 @@ LDFLAGS:=$(shell dpkg-buildflags --get LDFLAGS) > > build3vers := $(shell py3versions -sv) > > -#build qt4 UI only > -export QMAKE=qmake-qt4 > +#build qt5 UI > +export QT_SELECT := qt5 > > ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) > CFLAGS += -O0 > xapplication/pgp-signature [Click mouse-2 to save to a file]
Bug#784523: Bumping severities
Lisandro Damián Nicanor Pérez Meyer writes: > severity 784619 normal > severity 784513 normal > severity 784514 normal > severity 784522 normal > severity 784523 normal > severity 784524 normal > severity 784525 normal > severity 784613 normal > severity 784532 normal > severity 784618 normal > thanks > > Hi! As we intend to go further with this removal we are bumping it's > severity. > If you need help please do not hesitate in replying to the bug, I am > subscribed to it. Hi, As far as I know, Recoll builds fine with qt5-webkit > 5.2. Just get rid of the QMAKE=qmake-qt4 line in the rules. Cheers, J.F. Dockes
Bug#772171: Shouldn't this have a higher severity?
John Eikenberry writes: > > Doesn't this bug make it impossible to index any new data? Shouldn't it have > a > higher severity than normal? It completely breaks recoll for my use, so I'd > give it grave unless there are other use cases where it still works. > > Error output I get when I run 'recollindex'... > > :2:../index/indexer.cpp:298:ConfIndexer::createAspellDict: aspell init > failed: Could not open shared library [/usr/lib/libaspell.so] > [/usr/lib/libaspell.so.15] [/usr/lib/libaspell.so.16] > [/usr/lib64/libaspell.so] [/usr/lib64/libaspell.so.15] > [/usr/lib64/libaspell.so.16] : /usr/lib64/libaspell.so.16: cannot open > shared object file: No such file or directory Hi, This will not be fixed in recoll 1.17 (too old), and it is already fixed in recoll 1.21, which is currently in sid. For now: - To fix the .so load issue (message above), on a Wheezy or Jessie system, upgrade to recoll 1.21 through the recoll repository, see instructions on the page which follows, look for the packages section: http://www.lesbonscomptes.com/recoll/download.html - You may hit another dictionary creation issue, which is described near the top of the following page (search for aspell), along with a simple workaround. http://www.lesbonscomptes.com/recoll/BUGS.html Cheers, jf
Bug#772171: (recoll: /usr/lib/libaspell not present)
Bruce Johnson writes: I upgraded to a newer version of recoll as per instructions (http://www.lesbonscomptes.com/recoll/download.html) under ubuntu. Im still getting the aspell error...? [...] :2:../index/indexer.cpp:351:ConfIndexer::createAspellDict: aspell buildDict failed: aspell dictionary creation command failed: /usr/bin/aspell --lang=en --encoding=utf-8 create master /home/bruce/.recoll-syn/aspdict.en.rws [...] /usr/lib/aspell/en.dat Hi, It seems that you have hit the problem described at the top of this page: http://www.lesbonscomptes.com/recoll/BUGS.html This was a Debian Jessie issue (I think that the aspell packagers were working on a fix), but it apparently found its way into Ubuntu. Please try the workaround from the document (link the .dat files from /usr/lib/aspell to /usr/share/aspell). Cheers, jf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778102: recoll: ftbfs with GCC-5
Just to confirm, I installed Debian testing and gcc-5. Recoll builds fine with gcc-5 as long as the installed Xapian (libxapian-dev) itself was built with gcc-5. This is definitely either a Xapian or build system issue, not a Recoll one, and I don't even see a possible workaround on the Recoll side. Cheers, jf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778102: recoll: ftbfs with GCC-5
Seems I can't reach Kartik Mistry by direct email, trying through the bug report: The diagnostic from the log is a Xapian one, saying that they are trying to build Recoll with a compiler ABI version which is not the same as the one which was used to build the Xapian library. The include file which causes the issue (xapian/version.h) is created during the Xapian build. The lines which cause the error are the following: #ifdef __GNUC__ #if __GNUC__ 3 || (__GNUC__ == 3 __GNUC_MINOR__ == 0) #error Xapian no longer supports GCC 3.1 #else #if !defined(__GXX_ABI_VERSION) || __GXX_ABI_VERSION != 1002 #error The C++ ABI version of compiler you are using does not match #error that of the compiler used to build the library. The versions #error must match or your program will not work correctly. #error The Xapian library was built with g++ 4.7.2 #endif I initially saw 2 possibilities here: - Either they are actually building Recoll with gcc5 with a libxapian dev package which was created with gcc4 (then I guess that their method is wrong, they should build the dependancy packages before the ones which depend on them). - Or the test in the Xapian file is wrong or incompatible with gcc 5 (then it's a Xapian bug). I don't see how this could possibly be a Recoll issue. Except maybe if this is related to how the libxapian dependancy is expressed in the recoll package ? Actually, I checked with other xapian-based packages (e.g. xapian-omega itself) and the builds fail with the same error. https://people.debian.org/~doko/logs/gcc5-20150205/xapian-omega_1.2.19-1_unstable_gcc5.log So this really seems a problem with the package rebuild method. It seems that it is necessary to build and install libxapian with gcc5 before they building dependant packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784540: recollindex always indexes /tmp despite being given a different path
The attached patch checks that all topdirs elements are absolute paths before starting the indexing. The change will be in all future releases until relative paths can be properly supported. Cheers, jf recoll-check-topdirs-abs.diff Description: Binary data
Bug#784540: recollindex always indexes /tmp despite being given a different path
Helmut Grohne writes: Control: severity -1 normal Control: retitle -1 topdirs no longer accepts relative paths Thanks for your quick reply! On Wed, May 06, 2015 at 04:42:02PM +0200, Jean-Francois Dockes wrote: The way to specify things to be indexed is to set the topdirs variable inside someconfdir/recoll.conf. This can be set by editing the file or from the indexing configuration section of the GUI. What is the value of this variable inside 'someconfdir' in the above test ? My topdirs variable is set to ./. It looks like the issue relates to relative paths only. Furthermore, additional args have always been ignored by recollindex if neither -i nor -e was set. I just checked that this was true of 1.17 Did you actually mean to type -i some/path in the above report ? Probably. I tried both with -i and without -i. The behaviour for the new version would always be to only consider files below /tmp. Given the above I guess that my issue relates to recollindex having added a call to chdir that was not present in the old version: http://sources.debian.net/src/recoll/1.20.3-2/index/recollindex.cpp/#L403 I am not sure whether the issue at hand is worth fixing at all or whether I just need to update my configuration in a suitable way. Possibly the value of topdirs could be canonicalized using realpath prior to invoking chdir? That's probably just the tip of the iceberg though. I think that you have explained everything, and found a an error-checking + doc bug. Relative paths in topdirs, should either be banned or be made absolute, not against the current directory, but against the configuration directory itself. You are right that the chdir() to /tmp is what put the problem in evidence. The reason for doing this is that some of the helper programs used by recoll have a tendancy to leave temporary files around, which is best done in /tmp. It's very weird that nobody ever hit this to this day... Even without the chdir(), the fact that the data being indexed depended on the cd was quite unsound (starting indexing from the wrong place would empty the index as I just saw...). Otoh, as paths are made absolute during indexing (against the current directory, both 1.17 and 1.20), search result preview/open would work from any location. All topdirs examples in the doc are with absolute paths, but there is nothing that explicitely bans relative paths. And the chdir has been in there for around 2 years, many people have run with it. 10 years of recoll and still surprises... So for the followup: - On your side, please use absolute paths inside recoll.conf. This is the workaround for now. - The next minor Recoll release will generate an error if relative paths are found in topdirs. - I am going to think a bit more about this. If confdir-relative paths can make sense in some circumstances (maybe they could have a use for removable media if I can make it work), I'll change the code to make it useful, but this is a big change, maybe in 1.21 If you can think of a good reason to keep relative paths against the current directory working, I am quite interested by your observations. In any case, thank you very much for tracking this out and finding the root cause. Cheers, jf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784540: recollindex always indexes /tmp despite being given a different path
Helmut Grohne writes: Package: recoll Version: 1.20.3-2 Severity: important File: /usr/bin/recollindex recollindex -c someconfdir some/path used to index to index some/path. Since upgrading from 1.17.3-2 to 1.20.3-2 it indexes /tmp instead. It seems that the new version does not provide any means to index files outside /tmp. If this observation is wrong, please downgrade the severity of this bug. Helmut The way to specify things to be indexed is to set the topdirs variable inside someconfdir/recoll.conf. This can be set by editing the file or from the indexing configuration section of the GUI. What is the value of this variable inside 'someconfdir' in the above test ? Furthermore, additional args have always been ignored by recollindex if neither -i nor -e was set. I just checked that this was true of 1.17 Did you actually mean to type -i some/path in the above report ? In this case, some/path still needs to be inside the indexed area. I just also checked that this was already the case with 1.17 Test: recollindex 1.17.4, ~/projets is not in topdirs: recollindex -c ~/.recoll -i ~/projets Diagnostic in the log file: :4:../index/fsindexer.cpp:168:FsIndexer::indexFiles: skipping [/home/dockes/projets] (ntd) (ntd means not in top dirs). So, at this point, I am at a loss to explain what you could do with 1.17 that you can not do with 1.20... Regards, Jean-Francois Dockes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781876: libupnp6: Device built on ipv6-enabled libupnp fails if ipv6 not present in running kernel.
Package: libupnp6 Version: 1:1.6.19.jfd1-1 Severity: normal Tags: ipv6 Dear Maintainer, Newer versions of libupnp6 in Squeeze and later are configured with --enable- ipv6 The device part of such a library (miniserver) will not start if the running kernel does not contain ipv6 code. This is not the case for standard Debian kernel, but it happens with some derivative distributions, e.g. at least Raspbian. Raspberry Pis make nice multimedia devices, so Raspbian is an important platform for UPnP-related packages. I have no way to know if a future Raspbian based on Squeeze would still have ipv6-less default kernels, but if this proves to be the case, this problem becomes a major issue. It would of course possibly also affect people running Debian with custom ipv6-less kernels. A patch has been submitted to upstream to let the library start up in ipv4-only mode in this situation. http://sourceforge.net/p/pupnp/patches/60/ Two possible approaches to fix the problem would be to either reverse the --enable-ipv6 change (previous versions were built without it), or apply the correction. -- System Information: Debian Release: 7.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libupnp6 depends on: ii libc6 2.13-38+deb7u8 ii multiarch-support 2.13-38+deb7u8 libupnp6 recommends no packages. libupnp6 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#772415: aspell expects en.dat in /usr/share/aspell but it is in /usr/lib/aspell
Agustin Martin writes: I have comitted the relevant changes to our git repo and uploaded aspell with them to experimental, so testing is better before we upload to sid. Comments are welcome. Here is what I did to test the new packages: - Removed all traces of aspell from up to date Jessie system (dpkg -r aspell libaspell15 aspell-en + manual cleanup of misc trials). - Installed aspell packages from experimental + en package from sid: sudo dpkg -i aspell_0.60.7~20110707-2~exp1_amd64.deb \ libaspell15_0.60.7~20110707-2~exp1_amd64.deb \ aspell-en_7.1-0-1.1_all.deb - Tested recoll indexing, directory creation worked fine. - Replaced aspell with standard Jessie packages - fails again I far as I can see, the new packages fix the problem. Best regards, J.F. Dockes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772415: aspell expects en.dat in /usr/share/aspell but it is in /usr/lib/aspell
Agustin Martin writes: 2014-12-06 16:46 GMT+01:00 Jean-Francois Dockes j...@dockes.org: Package: aspell Version: 0.60.7~20110707-1.3 Severity: important Dear Maintainer, Hi, While fixing a problem about recoll not finding libaspell (Bug#772171), I found that aspell directory creation did not work on Jessie: Example run: vj64$ /usr/bin/aspell --lang=en --encoding=utf-8 create master /home/dockes/.recoll/aspdict.en.rws Error: The language en is not known. This is probably because: the file /usr/share/aspell/en.dat can not be opened for reading. Indeed /usr/share/aspell/en.dat does not exist, but /usr/lib/aspell/en.dat does. Specifying --data-dir does not work either: vj64$ /usr/bin/aspell --data-dir=/usr/lib/aspell --lang=en --encoding=utf-8 create master /home/dockes/.recoll/aspdict.en.rws Error: The file /usr/lib/aspell/iso-8859-1.cset can not be opened for reading. Does --local-data-dir work? aspell-autobuildhash creates hashes with something like zcat /usr/share/aspell/es.cwl.gz | precat | aspell --per-conf=/dev/null --local-data-dir=/usr/lib/aspell --lang=es create master /var/lib/aspell/es.rws and works smoothly. Yes, this works, but it was not necessary on Wheezy (or any other system on which Recoll runs, including non-Linux ones). If some reason lead to changing the location of certain aspell data files, it would seem reasonable that a corresponding change of the compiled-in defaults would let the command run without special arguments as it did in the past. Cheers, Jean-François Dockes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772415: aspell expects en.dat in /usr/share/aspell but it is in /usr/lib/aspell
Package: aspell Version: 0.60.7~20110707-1.3 Severity: important Dear Maintainer, While fixing a problem about recoll not finding libaspell (Bug#772171), I found that aspell directory creation did not work on Jessie: Example run: vj64$ /usr/bin/aspell --lang=en --encoding=utf-8 create master /home/dockes/.recoll/aspdict.en.rws Error: The language en is not known. This is probably because: the file /usr/share/aspell/en.dat can not be opened for reading. Indeed /usr/share/aspell/en.dat does not exist, but /usr/lib/aspell/en.dat does. Specifying --data-dir does not work either: vj64$ /usr/bin/aspell --data-dir=/usr/lib/aspell --lang=en --encoding=utf-8 create master /home/dockes/.recoll/aspdict.en.rws Error: The file /usr/lib/aspell/iso-8859-1.cset can not be opened for reading. Indeed, iso-8859-1.cset is in /usr/share/aspell. It used to live in /usr/lib/aspell on Wheezy The same command works on Wheezy. Apparently 2 things have changed: the default data-dir is /usr/share/aspell, when it used to be /usr/lib/aspell, but not all of the data files moved from /usr/lib/aspell to /usr/share/aspell, so the configuration now appears inconsistent. -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages aspell depends on: ii dictionaries-common 1.23.17 ii libaspell15 0.60.7~20110707-1.3 ii libc62.19-13 ii libgcc1 1:4.9.1-19 ii libncursesw5 5.9+20140913-1 ii libstdc++6 4.9.1-19 ii libtinfo55.9+20140913-1 Versions of packages aspell recommends: ii aspell-en [aspell-dictionary] 7.1-0-1.1 Versions of packages aspell suggests: pn aspell-doc none pn spellutils 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#772171: (recoll: /usr/lib/libaspell not present)
I created a fix for this: https://bitbucket.org/medoc/recoll/commits/e247474aaf254ef4d119947660c9b2ed133cdaf1 But while doing this, I found another Recoll/Aspell problem on Jessie: see Bug#772415, so the Recoll aspell dictionary creation does not work, even with the above fix. APM writes: Hello, here's the complete message: :2:../index/indexer.cpp:298:ConfIndexer::createAspellDict: aspell init failed: Could not open shared library [/usr/lib/libaspell.so] [/usr/lib/libaspell.so.15] [/usr/lib/libaspell.so.16] [/usr/lib64/libaspell.so] [/usr/lib64/libaspell.so.15] [/usr/lib64/libaspell.so.16] : /usr/lib64/libaspell.so.16: cannot open shared object file: No such file or directory /usr/lib/libaspell ist nicht vorhanden, libaspell15 ist installiert, /usr/lib/64 ist nicht vorhanden Here's the output from locate aspell https://debianforum.de/forum/pastebin.php?mode=views=38149 Kind regards Axel Am Freitag, den 05.12.2014, 19:12 + schrieb Debian Bug Tracking System: Thank you for filing a new Bug report with Debian. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. As you requested using X-Debbugs-CC, your message was also forwarded to apschwim...@apmland.de (after having been given a Bug report number, if it did not have one). Your message has been sent to the package maintainer(s): Kartik Mistry kar...@debian.org If you wish to submit further information on this problem, please send it to 772...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768799: recoll: Version should be updated because of index corruption bug
Package: recoll Severity: important Dear Maintainer, Recoll versions up to 1.19.14 contain an issue (http://www.recoll.org/release-1.19.html#rodb) which, in conjunction with a Xapian one (http://trac.xapian.org/ticket/645) can cause index corruption. The consequence is mostly repeated indexing of documents at each incremental pass, but also possibly query errors. This is a random issue, relatively difficult to reproduce, but it is probably dependant on timing issues (this is NOT a multithreading bug though, it is seen in single-thread mode). Users who experience it see it rather frequently, some others never see it. In any case, it is fixed in 1.19.14 The package should be updated to the latest version: 1.19.14p2. As far as I know, the bug is also present in 1.17, which is also shamefully ancient. J.F. Dockes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674756: recoll: opens compressed text-files with gnumeric
Martin Ziegler writes: Package: recoll Version: 1.17.2-1 Severity: important In the new version the gui opens compressed textfiles (like textfile.txt.gz, textfile.txt.bz2, textfile.txt.zip) with gnumeric. This is because the uncompressed files are saved in temporary files like /tmp/rcltmpfchWV69.csv, which are then opened with xdg-open. Regards, Martin Hi, You can apply the attached patch to the central configuration (or the one in the source), or perform the equivalent modifications to your personal configuration, it should fix the issue. What it does is say that .csv files should be indexed as text/plain, but processed as a separate type otherwise. This will avoid chosing csv when looking for an appropriate suffix for text/plain... In ~/.recoll this would become: -- mimemap: .csv = text/x-csv -- mimeview: [view] text/x-csv = libreoffice %f -- mimeconf: [index] text/x-csv = internal text/plain [icons] text/x-csv = txt [categories] # Add text/x-csv to the text category list Cheers, jf txtcsvopen.diff Description: Binary data
Bug#674756: recoll: opens compressed text-files with gnumeric
Jean-Francois Dockes writes: Martin Ziegler writes: Package: recoll Version: 1.17.2-1 Severity: important In the new version the gui opens compressed textfiles (like textfile.txt.gz, textfile.txt.bz2, textfile.txt.zip) with gnumeric. This is because the uncompressed files are saved in temporary files like /tmp/rcltmpfchWV69.csv, which are then opened with xdg-open. Regards, Martin Hi, You can apply the attached patch to the central configuration (or the one in the source), or perform the equivalent modifications to your personal configuration, it should fix the issue. What it does is say that .csv files should be indexed as text/plain, but processed as a separate type otherwise. This will avoid chosing csv when looking for an appropriate suffix for text/plain... Sorry, the attached patch was for the trunk, it does not apply to 1.17 (I had to add a line just at the place where it wouldn't work...). Appropriate patch attached here. jf txtcsvopen-1.diff Description: Binary data
Bug#636221: recoll ships own xdg-open, doesn't use system provided one
Kartik Mistry writes: forwarded 636221 Jean-Francois Dockes j...@dockes.org thanks On Wed, Aug 3, 2011 at 8:21 PM, Jean-Francois Dockes j...@dockes.org wrote: Just for the record, and not to leave this on a wrong understanding. Recoll is designed to look for xdg-open in the PATH and only use its own copy as a last resort, and in general, this is what it does. I don't know why this doesn't work for you, this is either a recoll bug (which I would like to fix), or a misconfiguration issue. Have we looked into this in recent version of recoll? I looked at the code in 1.13, 1.14, 1.15, 1.16 and this was fixed in recoll 1.14. My apologies, I had not noticed that this bug report was about 1.13 at the time, always thinking about the latest. I can definitely confirm it by looking at the code. I think that modifying the code for such an old version is not a good idea. I have two possible workarounds which will work as long as xdg-utils is installed. I guess that adding a depend on xdg-utils would be for free as it is most probably installed with any desktop. - Either remove /usr/share/recoll/filters/xdg-open after install - Or patch the sampleconf/mimeview file (which get installed to /usr/local/share/recoll/examples). Change xdg-open to /usr/bin/xdg-open : --- a/src/sampleconf/mimeview Mon Oct 10 10:23:41 2011 +0200 +++ b/src/sampleconf/mimeview Fri Nov 11 09:11:53 2011 +0100 @@ -6,7 +6,7 @@ [view] # Pseudo entry used if the 'use desktop' preference is set in the GUI -application/x-all = xdg-open %f +application/x-all = /usr/bin/xdg-open %f application/x-kword = kword %f application/x-abiword = abiword %f Cheers, jf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614760: [PATCH] plug conversion descriptor leak in unac.c::convert() error path
Kartik Mistry writes: On Wed, Oct 12, 2011 at 12:36 PM, Jean-Francois Dockes j...@dockes.org wrote: The iconv_close() leak was fixed in recoll 1.16 (incidentally to another change), but it is present in 1.13, 1.14, and 1.15 (same unac.c file). The following patch fixed my problem. VSZ peaks around 160 MB. The original patch needed --ignore-whitespace to apply, I am attaching one with the same changes, but which should apply cleanly (if Kartik can make use of it). Sorry for late reply. Since this patch is already applied in version we've in Wheezy and Sid, and not in Sqeeze, I need to update package for Stable update. Or do you want me to backport current version to Squeeze? (This is specially for Ersek Laszlo :)). Just my 2 cents about the problem, as this is really an issue between the kind packager and Debian users :) : - The problem has been reported at least by another user (on Ubuntu), so it's probably relatively common. - As far as I can see, it can mostly (or only) be triggered by members inside zip archives, because of the way the transcoding is (not) handled for these. Cheers, jf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614760: [PATCH] plug conversion descriptor leak in unac.c::convert() error path
Ersek, Laszlo writes: Sorry for the delayed answer. On Mon, 10 Oct 2011, Jean-Francois Dockes wrote: It would seem that there is some file in your document set which is crashing recoll. We need to determine which it is, get it out of the indexed set so that you can begin to use recoll again, and if at all possible, I would very much like to get a copy to fix the bug (if this is confidential data, we'll try other ways to get details about the issue). For a beginning, we need to have a look at the log file before the point where recoll crashes. I rebuilt the package with noopt,nostrip,debug. I debugged it down to recoll-1.13.04/common/unacpp.cpp, function unacmaybefold(). It is called with dofold = true. unacfold_string() returns with -1, errno set to 12 (ENOMEM). Then unacmaybefold() goes on to format an error message: Thanks a lot for taking the time to debug this ! [...] I identified the file that caused this huge number of conversion errors -- it's a Maildir file with a zip and a rar attachment. Both compressed files have the same contents: two latin2 encoded text files (tables, actually), 1.3 and 1.4 MB in size. In total 5.4 MB of latin2 encoded text that caused 90,228 conversion failures (and presumably leaked the same number of conv descs). [...] I'd guess that you have an utf-8 locale. Recoll has no good way to identify the character set when it is not told (by a file header or the locale or a configuration option). The next version will be less verbose about conversion errors and probably will have an error percentage threshold after which it will just stop indexing the file. The iconv_close() leak was fixed in recoll 1.16 (incidentally to another change), but it is present in 1.13, 1.14, and 1.15 (same unac.c file). The following patch fixed my problem. VSZ peaks around 160 MB. The original patch needed --ignore-whitespace to apply, I am attaching one with the same changes, but which should apply cleanly (if Kartik can make use of it). Again, many thanks. Regards, jf patch-unac-icclose.diff Description: Binary data
Bug#614760: 1.13.04-3+b1 crashes too
Ersek, Laszlo writes: package recoll severity 614760 grave thanks Ran recollindex from a terminal. It printed a zillion lines of :3:../rcldb/rcldb.cpp:813:Db::splitter::takeword: unac failed for [...] then finally terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc RCLMFILT: rclzip : : EOF on input Aborted Actually, what's worst is that after dist-upgrading from Lenny to Squeeze, recollindex simply refused to open the xapiandb that was created under Lenny: :2:../rcldb/rcldb.cpp:611:Db::open: exception while opening [/home/lacos/.recoll/xapiandb]: Recoll index version mismatch This is normal, the index format changed, you need a full index, this was probably listed somewhere in the release notes. So I tried recollindex -z and then even manually removing xapiandb/ before reindexing, but both of these crashed. I retried indexing from the GUI. That crashed too. Currently I can't reindex my local imap mirror, nor can I use my previous index. This makes recoll unusable for me. It would seem that there is some file in your document set which is crashing recoll. We need to determine which it is, get it out of the indexed set so that you can begin to use recoll again, and if at all possible, I would very much like to get a copy to fix the bug (if this is confidential data, we'll try other ways to get details about the issue). For a beginning, we need to have a look at the log file before the point where recoll crashes. Please see the Obtaining information from the log file section on this page for doing this: https://bitbucket.org/medoc/recoll/wiki/GettingAStackTrace Regards, jf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643021: [recoll] Forked CLI call does not return (all) hits
Denis Prost writes: Attached are 4 log files : * one from recoll -t -q gazette (155 results) * one from recollrunner with the same query (only default query language checked in recollrunner config) (3 results : only the ones among the 155 which do not contain spaces in their pathes) * one from recoll -t -f -q gazette (46 results) * one from recollrunner with the same query (default query language checked and match filenames checked in recollrunner config) (0 result) I hope it will help solving this issue. Regards Denis Thanks a lot for the log files, my comments below: first: :4:../rcldb/rcldb.cpp:1525:Rcl::Db::filenameWildExp: pattern: [*gazette*] My guess is that this is from the 3d query (recoll -t -f -q gazette). The -q which would specify a query language query is ignored (because of how the options are parsed), and this is a filename query where gazette is transformed to *gazette* because it is neither capitalized nor contains wildcards. It is supposed to return all documents with [gazette] as part of their file name. Second: :4:../rcldb/searchdata.cpp:782:StringToXapianQ:: query string: [gazette] This is from [recoll -t -q gazette], which is a regular text search query, returning all documents with gazette or a derivative ([gazettes]) in the contents, or possibly in the file name field processed as text. Third: :4:../rcldb/searchdata.cpp:782:StringToXapianQ:: query string: ['gazette'] This is probably from recollrunner with only 'default query language' checked: there is excessive quoting, but it doesn't hurt much because this is a full text search and the quotes get eliminated. I don't know why recollrunner returns few results, but as you mention that these are only the ones without spaces in the file name, I'd suspect a problem parsing the output from recoll. Fourth: :4:../rcldb/rcldb.cpp:1525:Rcl::Db::filenameWildExp: pattern: [*'gazette'*] This is with recollrunner, match filenames and default query language checked. Match filename takes precedence and the query fails because of the excessive quoting. The only thing that I find strange in the logs is that the 3rd one seems to indicate that the query actually returns more results than the 1st one, when I would have thought that they are identical. But the quoting may have affected the query, the actual Xapian query is truncated in the log for some reason, so we can't be sure: :4:../rcldb/rclquery.cpp:237:Query::SetQuery: Q: ((gazette:(wqf=11) OR gazettes OR gazet:4:../rcldb/rclquery.cpp:344:Fetching for first 50, count 50 So I think that the first fixes should be for recollrunner to: - Avoid excessive single quote quoting - Indicate somehow that query language and file name search are different and exclusive modes. - Try to better parse the query output when there are spaces in the file names. And then we may get into possible Recoll issues. I'd be quite interested though by the logs from the 2 following commands: recoll -t -q gazette recoll -t -q 'gazette' Cheers, Jf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643021: [recoll] Forked CLI call does not return (all) hits
David Baron writes: On Wednesday 29 Elul 5771 09:35:41 Jean-Francois Dockes wrote: This is probably from recollrunner with only 'default query language' checked: there is excessive quoting, but it doesn't hurt much because this is a full text search and the quotes get eliminated. I don't know why recollrunner returns few results, but as you mention that these are only the ones without spaces in the file name, I'd suspect a problem parsing the output from recoll. I am no longer quoting filename searches. I have changed the stdout line parsing to .[ -- mimetype after trimming [..] -- URL/path [] -- name, title, etc ... Spaces are not used for anything (except removed from the mimetype). I can see filenames with spaces. krunner seems to be not including every match I feed to it. In other words, I know I am getting three filename results into the program but only one of them (first one?) actually gets displayed. This may be why Denis only still sees three of his gazettes (unless this is still the space problem). In any event, I may post next week a new version on kde-apps. Ok, I don't know enough about krunner to be of real usefulness here. We should be aware that the recollq/recoll -t output is not fully parseable at this point (a file name with ']' in it would break it). If you can get the krunner part to behave, and if you decide that the current approach is the sensible one (as compared to using an API), I could easily be convinced to provide a fully and easily parsable output format (for example by encoding the data parts in base64), we can talk about this. Cheers, jf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643021: [recoll] Forked CLI call does not return (all) hits
David Baron writes: Package: recoll Version: 1.16.0-1 Severity: important --- Please enter the report below this line. --- I am running recoll -t from a krunner plugin, i.e. forking it in the background. This worked fine while back. However, now (last few versions), using the -f (filename search) option returns no hits at all. Users of this plugin has also reported far too few hits on default searches. Debugging code showed correct command string and then XFNONE, 0 results strings returned. Simply running the same command in a console works fine, allbeit it sometimes with differing results than in the GUI program. Note that users had reported problems with permissions on multi-user systems so this may be a place to look. Hello, It would be very helpful to have the log files for running the command in a console and through krunner. Please either set up recoll to log to a file, or arrange to retrieve stderr output, and set the debug level to 6, either through the config GUI or by editing ~/.recoll/recoll.conf: logfilename=/some/file/name loglevel = 6 - Run the search in a console. - Save the log file (it will be erased at the next step) - Run the same search from krunner. - Save the log file. Then please send both logs to me (jfd at recoll dot org). More than permissions (which are there to be observed), one possible area of concern might be wildcard character expansion by the shell: use proper quoting when running in the console (ie: recoll -t -f 'there *re *ildcards'), and we'll probably have to check how krunner executes the command too, but this kind of issue should be visible in the log file anyway. Regards, jf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643021: [recoll] Forked CLI call does not return (all) hits
David Baron writes: Log files enclosed: console-log from console krunner-log from krunner Note that the krunner one has a query *'downloads'* !! I do not do this, obviously. I have asked a correspondant to do this same test with a non -f test which was also not succeding but returning 3 / 150 hits. Ok, thanks for the logs, they make it clearer what is happening here. From krunner: :4:../rcldb/rclquery.cpp:174:Query::setQuery: :4:../rcldb/rcldb.cpp:1525:Rcl::Db::filenameWildExp: pattern:[*'Downloads'*] Command line: :4:../rcldb/rclquery.cpp:174:Query::setQuery: :4:../rcldb/rcldb.cpp:1525:Rcl::Db::filenameWildExp: pattern: [Downloads] I will be using [] for quoting in the rest of the message (the [] are not part of the strings). First a bit of explanation on the handling of file name searches: recoll will prepend and append a [*] to a file name search if it does not already contain wildcards and is not capitalized. Trying to do the right thing here, but maybe being slightly too clever. So the krunner search is expanded from ['Downloads'] to [*'Download'*] because ['] is not a capital (not punctuation either because of searches like o'donnell etc.) The second search is not expanded because [D] is a capital. Alternatively, searching for [download] would yield a [*download*] search. This is all particularly ennoying because it does not show in the end search, which only has the XNONENoMatchingTerms thing, because expansion actually occurs (or not) before the search is passed to Xapian. I'll easily admit that the Recoll choices are dubious here (I'm open to suggestions), and I was going to write that I'd least document this disconcerting behaviour of the file name search, but in fact, it is, already: http://www.recoll.org/usermanual/rcl.search.html#RCL.SEARCH.SIMPLE The actual problem here seems to be too much quoting in the data sent by krunner. The parameter incoming to recoll is really ['Download'] when it should just be [Download]. This might also cause the other query issues that you mention. What's strange is that such a krunner issue should also show with other commands ? Or was the search actually entered with single quotes in the krunner window ? I can't really guess what happens or should be done here because I don't know how krunner executes commands (sh -c or exec(2) or whatever...) Getting close... Cheers, jf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643021: [recoll] Forked CLI call does not return (all) hits
David Baron writes: On Tuesday 28 Elul 5771 17:26:33 David Baron wrote: On Tuesday 28 Elul 5771 17:04:29 Jean-Francois Dockes wrote: David Baron writes: Log files enclosed: console-log from console krunner-log from krunner Note that the krunner one has a query *'downloads'* !! I do not do this, obviously. I have asked a correspondant to do this same test with a non -f test which was also not succeding but returning 3 / 150 hits. Ok, thanks for the logs, they make it clearer what is happening here. From krunner: :4:../rcldb/rclquery.cpp:174:Query::setQuery: :4:../rcldb/rcldb.cpp:1525:Rcl::Db::filenameWildExp: :pattern:[*'Downloads'*] Command line: :4:../rcldb/rclquery.cpp:174:Query::setQuery: :4:../rcldb/rcldb.cpp:1525:Rcl::Db::filenameWildExp: pattern: [Downloads] I will be using [] for quoting in the rest of the message (the [] are not part of the strings). First a bit of explanation on the handling of file name searches: recoll will prepend and append a [*] to a file name search if it does not already contain wildcards and is not capitalized. Trying to do the right thing here, but maybe being slightly too clever. So the krunner search is expanded from ['Downloads'] to [*'Download'*] because ['] is not a capital (not punctuation either because of searches like o'donnell etc.) The second search is not expanded because [D] is a capital. Alternatively, searching for [download] would yield a [*download*] search. This is all particularly ennoying because it does not show in the end search, which only has the XNONENoMatchingTerms thing, because expansion actually occurs (or not) before the search is passed to Xapian. I'll easily admit that the Recoll choices are dubious here (I'm open to suggestions), and I was going to write that I'd least document this disconcerting behaviour of the file name search, but in fact, it is, already: http://www.recoll.org/usermanual/rcl.search.html#RCL.SEARCH.SIMPLE The actual problem here seems to be too much quoting in the data sent by krunner. The parameter incoming to recoll is really ['Download'] when it should just be [Download]. This might also cause the other query issues that you mention. What's strange is that such a krunner issue should also show with other commands ? Or was the search actually entered with single quotes in the krunner window ? I can't really guess what happens or should be done here because I don't know how krunner executes commands (sh -c or exec(2) or whatever...) The run is being done by a start( QString cmd, QStringList args ) type of fork. I, as recommended, place the query string argument in single quotes in the program, not in krunner's text line window. I assume the internal start() function is an exec but I could be wrong. Question, since the query string is a singe QString, last entry in the QStringList, should the quotes not be there? Within this list of arguments, there is no ambiguity. Question would be after it is expanded in the run shell, would the non-quoted string be problematic? You'd have to check what the start function actually does. If it starts a shell to execute the command, in a way which will make the wildcards expand (and the quoting be removed), you need quoting. Given the look of the call, I'd guess that it's closer to a simple fork/exec operation, meaning that no wildcard expansion will take place before recoll receives the arguments, and that you must not quote. Easy enough to try out but not knowing recoll's internals, cannot really touch all the bases. Recoll internals are not in cause here, you'd have the same problems executing vi or ls I tried it and lo and behold, I get filename search results. Ok, then confirmation of the fork/exec kind of spawn. A big question, however: The GUI implies and my results seem to indicate that the and/or/query-language options do not work with filenames. Is this true? Or would they work WITH the quotes (seems not to)? This is a GUI design issue since if filename is an exclusive option, then it would radio-button with the others or gray them if checkboxed. Hhm sorry, I'm a bit lost here, what radio-buttons ? I'm not sure what dialog we're talking about here ? Using the query language, filename queries can be normally combined in others ie, like in [wildcard filename:*manual*] (this would return among others usermanual.sgml which has the term [wildcard] in it). Using the simple search File name option, there is nothing to combine it with, this is a pure file name search. I think that this is more or less correctly described in the search section of the manual: http://www.lesbonscomptes.com/recoll/usermanual/rcl.search.html There many possible
Bug#643021: [recoll] Forked CLI call does not return (all) hits
Sorry forgot to answer to these in the previous email: David Baron writes: The * problem does not explain a non-filename problem--I hope the correspondent did the same tests and logfiles and sent them as I suggested to him. Excessive quoting may also affect non-filename searches, and there is also the capital issue, if the user is not careful about it, search results will be different (because of stemming/no stemming). Ultimately, I should probably take snippets from recoll's sources and do it directly to xapian rather than the fork, but this runner is meant to be simple and small. Performance in such an interactive environment is not an issue. Going directly to Xapian would be quite complex. Recoll does quite a lot of processing before asking stuff from Xapian, I would really not recommand this (except if you want to rewrite recoll :) ) Actually I think that your approach is quite reasonable. Another possibility would be to either use the Python API or the C++ interface which is just below this: as it's use to implement the Python and PHP Apis and also the recollq program, it's quite stable, and simple (take a look at recollq). The main problem going this way would be build issues, as Recoll is not currently structured to export a library (which is why the Python approach would really be the most natural, except that your program is C++ I guess). Cheers, JF -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636221: recoll ships own xdg-open, doesn't use system provided one
Daniel Skorka writes: On Mon, 1 Aug 2011 18:04:50 +0200 Jean-Francois Dockes j...@dockes.org wrote: As far as I know, recoll only uses its own (and stale) copy of xdg-open if the system one is not found in the PATH. I'd be interested by more detail about how it gets to execute its own copy. There is no doubt that recoll is using it's own copy instead of the xdg-utils one. Other programs use /usr/bin/xdg-open, and it works without a hitch. I tried debugging recoll, but did not have much success. However, doing an strace of recoll and it's children, I see first an access() to /usr/share/recoll/filters/xdg-open, then a clone() and then the child does execve(/bin/sh, [sh, -c, /usr/share/recoll/filters/xdg-op...] At no point does recoll look for /usr/bin/xdg-open. This is unlike xdg-mime, which it looks for, and finds, in /usr/bin Just for the record, and not to leave this on a wrong understanding. Recoll is designed to look for xdg-open in the PATH and only use its own copy as a last resort, and in general, this is what it does. I don't know why this doesn't work for you, this is either a recoll bug (which I would like to fix), or a misconfiguration issue. Cheers, jf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636221: recoll ships own xdg-open, doesn't use system provided one
Daniel Skorka writes: Hi, recoll ships with xdg-open in /usr/share/recoll/filters, and uses this instead of the one provided by xdg-utils in /usr/bin The problem is that the two differ in behaviour, so if Use desktop preferences to choose document editor in the configuration dialog is checked, the behaviour might actually be different from what the rest of the system does. I propose removing xdg-open from recoll, and simply having the package depend on xdg-utils instead. Best regards, Daniel Hi, As far as I know, recoll only uses its own (and stale) copy of xdg-open if the system one is not found in the PATH. I'd be interested by more detail about how it gets to execute its own copy. There was probably a reason to ship a copy at some point in the past, but I forgot what it was, and depending on xdg-utils instead does seem quite reasonable. Cheers, jf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626882: recoll: segfault (in InitFldToPrefs via std::basic_string?)
Drew Parsons writes: Package: recoll Version: 1.15.8-1 Severity: grave Justification: renders package unusable After upgrading to recoll 1.15.8-1, it now segfaults on start. This is a static object initialization issue that I had seen on the Mac after releasing 1.15.8. It hadn't affected any of the other systems I had tested on, but apparently it works on debian 64 bits, for which I have no platform to test on. Hopefuly, the attached patch should fix the problem, it brings 1.15.8 to the current state of the 1.15 maintenance branch. I couldn't test it on debian, but it does fix the issue on the mac. Sorry about the trouble. jf recoll-staticfix.diff Description: Binary data
Bug#617353: recoll: Segmentation fault when file type radio button clicked
Cedric Scott writes: Package: recoll Version: 1.15.2-1 Severity: normal The subject line says it all. As an experiment I built 1.15.5 from source and it doesn't have this problem. Yes, it's a known bug, only happens when there is no current query (ie: just after start). This is fixed in 1.15.5. It's a very simple change and could be patched, but 1.15.5 has a few other bug fixes, so it may be better to upgrade. Patch: https://bitbucket.org/medoc/recoll/changeset/325a48cd23d8 jf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612047: recoll indexing fails - solution typo
Horvath Andras writes: Running these commands: updatedb locate recoll.conf I get the following results: /home/$USER/.config/Recoll.org/recoll.conf /home/$USER/.recoll/recoll.conf /usr/share/man/man5/recoll.conf.5.gz /usr/share/recoll/examples/recoll.conf The last one has filtersdir set. Just for the record, /home/$USER/.config/Recoll.org/recoll.conf contains settings for the recoll Qt GUI and has nothing to do with ~/.recoll/recoll.conf and /usr/share/recoll.conf. It's infortunate that they have the same name. It's a Qt-chosen name, that I could probably have overridden, but it's too late now. Cheers, jf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587684: recoll: use unuconv for MS Word documents
Celejar writes: Recoll currently uses antiword and catdoc for MS Word documents. Antiword claims to only support Word 2003 (according to the website) or lower, and catdoc only to Word 97 (according to the Debian package info). Unoconv claims to be able to support any documents that OO.org supports, so it should cover modern Word formats not covered by the current utilities. As far as I know, modern word formats, which I take to be Open Xml, are covered by a native filter (rclopxml), based on xsltproc. If there are specific issues and problem documents, it would be nice to please provide a sample. Testing on Open Xml documents has indeed been very minimal, so I would not be very surprised if there are issues. Cheers, jf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587684: recoll: use unuconv for MS Word documents
Celejar writes: Okay. I followed the troubleshooting advice from recoll's website, and it seems that the reason my docx's weren't being indexed was that xsltproc was not installed, and rclopxml needs it to run. So I guess that we need a suggests on xsltproc? This would be an option. My preference has been to set minimum dependencies and provide a way to list missing helper applications. There are probably quite a few people with no docx documents (I'm one of them). But this is really a matter of taste and compromise, and adding suggests certainly will not make me frown (none of my business anyway :)). Additionally libxslt/xsltproc are small and extremely common (and used by other recoll filters). If you use docx indexing, I'll be very interested to hear about any problem. Cheers, jf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569333: recoll: remove xpdf 'suggests' dependency
Celejar writes: While we're on this topic, I notice that there are 'suggests' for both antiword and catdoc. Is there an advantage in having both? catdoc is used for xls and ppt. Antiword is much better for msword documents, or at least was at the time when the choice was made. jf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513192: Recoll; Lenny
Kartik Mistry writes: On Thu, Jan 29, 2009 at 12:01 AM, Cropper, C. A. crop...@acm.org wrote: Considering that my computer is nearly unusable, if this bug is not grave or at least serious I don't know what is; I am removing recoll from my system. It NEVER finished the initial indexing. It crashes the ENTIRE system. I tried the sid version as well. Sad to hear this. Can you remove recoll and try once again installing it? It need to be reindex if you are using recoll from 'sid'. Hi, Kartik. Hello M. Cropper, I am the developper for Recoll. I am sorry for your trouble with it, it usually performs quite decently from what I hear. I just found out how to subscribe to the debian package tracking for Recoll by the way, and I'll be able to react faster in the future ... Would you be willing to help me solve the problem, or are you too disgusted with the software to even try ? I don't really understand how it crashes your system, I'd need a more precise description of what actually happens. About the indexer's crash, it would be very helpful to compile a version with debugging symbols and get a stack trace. I can help with a step by step description of how to do this if you can spare the time. I'll be out of email reach for the next week, but let me know if you want to pursue this, and I'll get in touch when I come back. Regards, J.F. Dockes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504876: Fwd: Bug#504876: recoll: The copy/paste buffer does not work
The Copy file name and Copy URL menu commands only copy the data to the primary X11 selection, which is probably a mistake. The next Recoll version will either copy to the clipboard or both the selection and clipboard (the latter would mimick a mouse-select + Ctrl-C, the exact operation the menu is supposed to make easier). For now, the workaround is to use a middle button mouse click to paste the primary selection to the desired target. jf Kartik Mistry writes: forwarded 504876 Jean-Francois Dockes [EMAIL PROTECTED] thanks Thanks for bug report, Alex. I am forwarding mail to upstream. ~ Kartik -- Forwarded message -- From: Alex [EMAIL PROTECTED] Date: Sat, Nov 8, 2008 at 12:27 AM Subject: Bug#504876: recoll: The copy/paste buffer does not work To: Debian Bug Tracking System [EMAIL PROTECTED] Package: recoll Version: 1.10.6-1 Severity: normal The copy url and copy file name do not work in Recoll. How to reproduce: Search for something in recoll such that there is at least one search result. Go to one of the results, and right click on the Open link and select Copy File Name. Now with Ctrl+V or a contextual menu try to paste the name of the file. Observe that the old contents of the copy/paste buffer are used. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (650, 'testing'), (600, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (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 recoll depends on: ii libc6 2.7-16GNU C Library: Shared libraries ii libgcc11:4.3.2-1 GCC support library ii libice62:1.0.4-1 X11 Inter-Client Exchange library ii libqt3-mt 3:3.3.8b-5Qt GUI Library (Threaded runtime v ii libsm6 2:1.0.3-2 X11 Session Management library ii libstdc++6 4.3.2-1 The GNU Standard C++ Library v3 ii libx11-6 2:1.1.5-2 X11 client-side library ii libxapian151.0.7-4 Search engine library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages recoll recommends: ii aspell0.60.6-1 GNU Aspell spell-checker Versions of packages recoll suggests: pn antiword none (no description available) pn catdoc none (no description available) ii ghostscript 8.62.dfsg.1-3.1 The GPL Ghostscript PostScript/PDF ii poppler-utils0.8.7-1 PDF utilitites (based on libpopple pn unrtfnone (no description available) pn xpdf none (no description available) -- no debconf information -- Cheers, Kartik Mistry | 0xD1028C8D | IRC: kart_ Homepage: people.debian.org/~kartik Blog.en: ftbfs.wordpress.com Blog.gu: kartikm.wordpress.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500690: [recoll] Problems with missing document handling packages
Peter Salisbury writes:
2008/9/30 Jean-Francois Dockes [EMAIL PROTECTED]:
If Peter can spare some time to do more testing, I'd be quite
interested by the output of the following sequence:
- Add loglevel = 4 to ~/.recoll/recoll.conf
- Uninstall the 3 helper packages, then:
time recollindex -z 2 /tmp/rcllog-znopack.txt
time recollindex2 /tmo/rcllog-nopack.txt
- Reinstall the 3 packages then:
time recollindex -z 2 /tmp/rcllog-zpack.txt
time recollindex2 /tmo/rcllog-pack.txt
Sorry it's taken a while, but here is the output you requested:
[skipped test results]
Thanks a lot for running these tests and sending the results.
It's quite reassuring that initial indexing works as expected.
About later indexing passes, I had another look at how Recoll *really*
works (as opposed to how I thought it worked :) ) and in fact, for file
types with missing helper applications, indexing is always retried (so that
it succeeds as soon as the helper is installed). Trying to execute the
filters wastes quite a lot of time.
This explains why the times go down after the helper is installed: the
files get indexed the first time, then nothing further happens if they stay
unchanged.
Recoll 1.11 has been modified to work slightly differently: executing a
missing filter is only tried once per indexing pass. The program then
remembers the failure and doesn't retry.
The files still get indexed at the first indexing pass following helper
installation, and there is almost no performance penalty for missing
helpers, best of both worlds (hopefully).
Thanks again for prompting me to implement this well-needed change.
Regards,
J.F. Dockes
$ time recollindex -z 2rcllog-znopack.txt
real8m48.449s
user3m49.958s
sys 2m57.675s
$ time recollindex 2rcollog-nopack.txt
real0m45.619s
user0m23.909s
sys 0m13.069s
re-install:
zlib1g-dev (1:1.2.3.3.dfsg-12)
libid3-3.8.3-dev (3.8.3-7.2)
libimage-exiftool-perl (7.30-1)
pstotext (1.9-4)
$ time recollindex -z 2rcllog-zpack.txt
real16m23.720s
user9m59.989s
sys 3m45.342s
$ time recollindex 2rcllog-pack.txt
real0m28.198s
user0m16.405s
sys 0m4.676s
The initial indexing is quicker without the helpers as you'd expect,
but the re-indexing is slower.
I can't send you the logs I'm afraid as they would be around 100MB but
I had a look in the re-indexing log when the helpers were absent and
there are lots of lines like this:
:4:../internfile/internfile.cpp:357:FileInterner::internfile. ipath []
:4:../utils/execmd.cpp:163:ExecCmd::doexec: ((nil)|0x9828eac)
/usr/share/recoll/filters/rclimg
{/home/peter/.gkrellm2-0/themes/minegue-beta/timer/bg_timer.png}
Can't locate Image/ExifTool.pm in @INC (@INC contains: /etc/perl
/usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5
/usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10
/usr/local/lib/site_perl .) at /usr/share/recoll/filters/rclimg line
61.
BEGIN failed--compilation aborted at /usr/share/recoll/filters/rclimg line
61.
:2:../internfile/mh_exec.cpp:71:MimeHandlerExec: command status 0x200:
/usr/share/recoll/filters/rclimg
:2:../internfile/internfile.cpp:412:FileInterner::internfile:
next_document error
[/home/peter/.gkrellm2-0/themes/minegue-beta/timer/bg_timer.png]
:2:../internfile/internfile.cpp:494:FileInterner::internfile:
conversion ended with no doc
:4:../rcldb/rcldb.cpp:1027:Db::add: docid 17360 updated
[/home/peter/.gkrellm2-0/themes/minegue-beta/timer/bg_timer.png , ]
:4:../internfile/internfile.cpp:109:FileInterner::FileInterner:
[/home/peter/.gkrellm2-0/themes/minegue-beta/bg_grid.png] mime
[(null)] preview 0
:4:../internfile/internfile.cpp:170:FileInterner::FileInterner:
image/png [/home/peter/.gkrellm2-0/themes/minegue-beta/bg_grid.png]
:4:../internfile/internfile.cpp:357:FileInterner::internfile. ipath []
:4:../utils/execmd.cpp:163:ExecCmd::doexec: ((nil)|0x97116b4)
/usr/share/recoll/filters/rclimg
{/home/peter/.gkrellm2-0/themes/minegue-beta/bg_grid.png}
Can't locate Image/ExifTool.pm in @INC (@INC contains: /etc/perl
/usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5
/usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10
/usr/local/lib/site_perl .) at /usr/share/recoll/filters/rclimg line
61.
BEGIN failed--compilation aborted at /usr/share/recoll/filters/rclimg line
61.
:2:../internfile/mh_exec.cpp:71:MimeHandlerExec: command status 0x200:
/usr/share/recoll/filters/rclimg
:2:../internfile/internfile.cpp:412:FileInterner::internfile:
next_document error
[/home/peter/.gkrellm2-0/themes/minegue-beta/bg_grid.png]
:2:../internfile/internfile.cpp:494:FileInterner::internfile:
conversion ended with no doc
HTH, Peter
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500690: [recoll] Problems with missing document handling packages
Hello, Kartik Mistry writes: On Tue, Sep 30, 2008 at 6:45 PM, Peter Salisbury [EMAIL PROTECTED] wrote: I installed recoll on a fairly sparse system and it took ages to index every time. It was only when I ran it from a terminal that I realised it was missing some required packages for indexing certain types of file. Ideally a better message would be given via the UI, and/or it would skip the types of file it can't index rather than take the time to fail at runtime. But perhaps at least these extra packages could be depend/recommend/suggested by recoll. The ones I had to install were: libimage-exiftool-perl libid3-3.8.3-dev pstotext I can think of no reason why Recoll indexing should be slower when the helper programs are not installed (so I'm quite probably missing something). I do agree that missing helpers should somehow be listed in the UI when indexing finishes, this has been on the todo list for ages, the difficulty is for the implementation not to get ennoying if the user doesn't want to install them. They are listed at the end of the error/debug log, but nobody looks at this of course. Normally, file types which can't be indexed by content (no helper package) are indexed by file name the first time, and then skipped if they don't change. After installing the helper, you need a full reindex (recollindex -z) to get them indexed. If Peter can spare some time to do more testing, I'd be quite interested by the output of the following sequence: - Add loglevel = 4 to ~/.recoll/recoll.conf - Uninstall the 3 helper packages, then: time recollindex -z 2 /tmp/rcllog-znopack.txt time recollindex2 /tmo/rcllog-nopack.txt - Reinstall the 3 packages then: time recollindex -z 2 /tmp/rcllog-zpack.txt time recollindex2 /tmo/rcllog-pack.txt The log files should at least contain file names, but they might also contain data in some error cases. If no confidentiality issues prevent it, and in case the timings of the first phase are indeed longer, I'd be quite interested to have a look at them. Really excellent program which found my file in the 'safe place' where I'd lost it! Great, I'm glad that this thing can be of some use from time to time ! Cheers, J.F. Dockes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471978: recoll: Does not respond to SIGTERM
Hi, I'm the Recoll developper. For some reason, I never got the messages about this problem. It is clearly a consequence of problem 471976 (excessive memory usage during indexing). Recoll can't exit without flushing the index (this would produce a corrupted database). So the alternative is to either rezero the index and exit immediately, or flush the data and hope it won't take too long. The second approach is more reasonable in most cases. It might be possible to differentiate INT, TERM and QUIT to optionally select the first one, but I doubt many people would bother. This problem is just a secondary effect, which will go away if a fix can be found for Bug#471976. jf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471976: recoll: Massive memory use on initial indexing
Greg Kochanski wrote: When my computer grinds to a halt because of your program, it's a bug. You can avoid calling it denial of service if you wish, but it's hard to think of other words to describe the condition. Kartik Mistry wrote: Unfortunately, there is no configuration for setting up RAM usage for recoll. Hello, I am the developper for Recoll. For some reason I never got copies of the messages about this problem (I found them by looking up Recoll on Google...) There is a configuration parameter for controlling Recoll memory usage during indexing, it's called idxflushmb, it was added in 1.9 (it is documented in the manual installation/configuration section). It is set quite low by default, and I'm surprised by what Greg is seeing here, I have not heard of such problems for quite some time. If Greg, or anybody with a similar issue, is willing to help me fix this by providing more details, running some tests, and maybe try corrections, please contact me. jf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
