Package Details: docfetcher 1.1.25-1

Git Clone URL: (read-only, click to copy)
Package Base: docfetcher
Description: A java open source desktop search application
Upstream URL:
Keywords: desktop productivity search
Licenses: EPL
Submitter: thiagowfx
Maintainer: macxcool
Last Packager: macxcool
Votes: 17
Popularity: 0.000000
First Submitted: 2014-05-01 20:55 (UTC)
Last Updated: 2021-05-25 23:57 (UTC)

Dependencies (4)

Required by (0)

Sources (4)

Latest Comments

galvez_65 commented on 2020-07-26 21:34 (UTC)

One question and one comment: comment: the docfetcher icon was not installed properly so I had to add the following to the PKGBUILD

  for icon in 16 24 32 48 64 128; do
    install -Dm644 "img/docfetcher${icon}.png" "${pkgdir}/usr/share/icons/hicolor/${icon}x${icon}/apps/${pkgname}.png"

question: is anyone having issues with the gtk3 version? some of the buttons like the run button in the index creation wizard are not showing up, I had to build using gtk2

ilf0 commented on 2020-05-05 08:31 (UTC)

@macxcool: Thanks, works nicely.

macxcool commented on 2020-05-01 11:44 (UTC)

Just set the depends to require Java>=8 with no upper bound.

ilf0 commented on 2020-05-01 10:26 (UTC) (edited on 2020-05-01 10:27 (UTC) by ilf0)

Cool, then let's adjust the dependency:

-depends=('java-runtime>=8' 'java-runtime<=10')

macxcool commented on 2020-04-30 16:11 (UTC)

Worked fine with 11 and 13 in my tests. Is that good enough?

macxcool commented on 2020-04-30 15:20 (UTC)

Just use archlinux-java to change your java environment to 11 or 13 and test docfetcher. There's probably no reason why it wouldn't work. If we get a couple of people reporting good tests, then I'll switch it. Maybe I'll just set it to >=8.

ilf0 commented on 2020-04-30 15:01 (UTC)

Upstream Java is now at 13.

Can we try docfetcher with Java 11, 12 and 13 and adjust the Java-dependency?

It's the only package why I still have Java 10 on my system, I'd like to get rid of it.

macxcool commented on 2018-08-15 19:36 (UTC)

I did a little testing with 1.1.22. It doesn't work with Java 7, but works with 8 and 10. I'll change the PKGBUILD accordingly.

davidmcinnis commented on 2018-05-20 08:26 (UTC) (edited on 2018-05-20 08:26 (UTC) by davidmcinnis)

Currently works with Java 8,

Does not work with Java 9 or Java 10.


macxcool commented on 2017-11-02 11:44 (UTC)

@simplexe: Ah. Sorry about that. It's actually there already, but there isn't a 'newline' before it. I'll fix that.

simplexe commented on 2017-11-02 06:43 (UTC)

Add to docfetcher.desktop type app. Like as: Type=Application

macxcool commented on 2017-05-16 12:02 (UTC) (edited on 2017-05-16 12:03 (UTC) by macxcool)

@languitar: That makes more sense. So like this: if [ $_gtkver == 'gtk3' ]; then #ln -s "${prefix}/" "${prefix}/" ln -s "/usr/share/${pkgname}/" "${prefix}/" makepkg doesn't seem to complain about it.

languitar commented on 2017-05-16 11:39 (UTC)

No wait. The problem is that the symlink originates from <thebuilddir>/usr/share... Instead, it must be from /usr/share to $prefix/use/share..., while ignoring the warning that the source file doesn't exist (yet, before the package is installed).

macxcool commented on 2017-05-16 11:37 (UTC)

@languitar: do you mean replace all instances of ${prefix} in the package() section with ${pkgdir}/usr/share/${pkgname}? I can do that. Is it always bad to use a variable to simplify typing paths in package() then?

languitar commented on 2017-05-16 10:40 (UTC)

Seems to be caused by using prefix as a variable. It should probably be pkgdir instead.

languitar commented on 2017-05-16 10:38 (UTC)

I see the problem: languitar@jaco ~/sciebo/literature/Citavi/thesis/Citavi Attachments> pacaur -Ql docfetcher | grep \\.sh docfetcher /usr/share/docfetcher/ docfetcher /usr/share/docfetcher/ docfetcher /usr/share/docfetcher/ languitar@jaco ~/sciebo/literature/Citavi/thesis/Citavi Attachments> which docfetcher /usr/bin/docfetcher languitar@jaco ~/sciebo/literature/Citavi/thesis/Citavi Attachments> docfetcher /usr/bin/docfetcher: line 3: /usr/share/docfetcher/ No such file or directory languitar@jaco ~/sciebo/literature/Citavi/thesis/Citavi Attachments [127]> cat /usr/share/docfetcher/ cat: /usr/share/docfetcher/ No such file or directory languitar@jaco ~/sciebo/literature/Citavi/thesis/Citavi Attachments [1]> ll /usr/share/docfetcher/ total 76K drwxr-xr-x 2 root root 4.0K Jan 10 16:36 conf/ drwxr-xr-x 3 root root 4.0K Jan 10 16:36 -rw-r--r-- 1 root root 30K May 16 12:34 docfetcher-daemon-linux -rwxr-xr-x 1 root root 310 Jan 10 16:36* -rwxr-xr-x 1 root root 291 Jan 10 16:36* lrwxrwxrwx 1 root root 95 May 16 12:34 -> /home/languitar/.cache/pacaur/docfetcher/pkg/docfetcher/usr/share/docfetcher/ drwxr-xr-x 5 root root 4.0K Jan 10 16:36 help/ drwxr-xr-x 2 root root 4.0K Jan 10 16:36 img/ drwxr-xr-x 2 root root 4.0K Jan 10 16:36 indexes/ drwxr-xr-x 2 root root 4.0K Jan 10 16:36 lang/ drwxr-xr-x 3 root root 4.0K May 16 12:34 lib/ drwxr-xr-x 2 root root 4.0K May 16 12:34 misc/ It seems the symlink for is corrupted and the build environment seems to leak into the creation of that link.

macxcool commented on 2017-04-30 12:40 (UTC)

@languitar I'm not sure what you mean. It all works for me still. /usr/share/docfetcher/ is in the package still and the 'docfetcher' script works. What are you seeing?

languitar commented on 2017-04-26 13:07 (UTC)

The included docfetcher script doesn't work anymore as the references script in the package has gone

macxcool commented on 2016-10-28 13:31 (UTC)

KDE should have nothing to do with variables in a shell script. I'm setting the value of $_gtkver to be 'gtk3' by default. It's only there so people have the choice of using GTK2 or 3. It's strange that you get no shortcut. I'll have a closer look at the script tonight.

pitlochry commented on 2016-10-28 12:31 (UTC)

I had to do the following fixes: sudo chmod 655 /usr/share/docfetcher/DocFetcher-GTK* sudo ln -s /usr/share/docfetcher/ /usr/share/docfetcher/ sudo sed -i s,"Icon=docfetcher","Icon=/usr/share/docfetcher/img/docfetcher128.png", /usr/share/applications/docfetcher.desktop sudo sed -i s,"Name=Docfetcher","Name=DocFetcher", /usr/share/applications/docfetcher.desktop The first one is already in, the second one can easily be fixed there. The third (no icon) and fourth (typing error) can easily be fixed in the desktop file. Thanks!

pitlochry commented on 2016-10-28 10:30 (UTC)

@ I use kde, so $_gtkver gives nothing (at least on my system). So there is no link made.

thiagowfx commented on 2016-10-24 05:19 (UTC)


macxcool commented on 2016-10-23 18:57 (UTC)

What do y'all think of this?

thiagowfx commented on 2016-10-23 16:59 (UTC) (edited on 2016-10-23 17:00 (UTC) by thiagowfx)

I am not currently using this software, so I can't advise. However, I'd say it's better to stick to one and only one. Choose gtk2 or gtk3, whatever you think it's more convenient. Since Arch supports gnome, which uses gtk3, I guess it would be a good default choice to make it more consistent with the rest of the system. And, if changing it to gtk2 is just a matter of changing one flag (like --use-gtk2 instead of --use-gtk3), then you could leave a comment so users can change it at their own discretion. All right?

macxcool commented on 2016-10-23 13:04 (UTC)

OK. Which of the two should we be using, or should we make both available? I also notice that both DocFetcher.GTK2 and DocFetcher.GTK3 are not chmod +x by default. Should we just use GTK3 by default? I suggest a symlink called to DocFetcher.GTK3 then? That's somewhat simpler and allows for an easy change to GTK2 for the user. We should also make GTK3 a dependency, shouldn't we?

davidmcinnis commented on 2016-09-14 05:10 (UTC) (edited on 2016-09-14 05:10 (UTC) by davidmcinnis)

Had to make the following change for docfetcher to start: docfetcher @@ -1,3 +1,3 @@ #!/bin/sh cd "/usr/share/docfetcher/" -exec ./ "$@" +exec ./ "$@"

thiagowfx commented on 2016-09-10 02:02 (UTC)


macxcool commented on 2016-09-09 16:28 (UTC)

Thx. I didn't realize there was a new version out ;-) Is the PKGBUILD adequate?

thiagowfx commented on 2016-09-09 16:23 (UTC)

bumped to 1.1.18

macxcool commented on 2016-05-14 15:16 (UTC)

I've updated to 1.1.17 and added a basic .desktop file. Please post if there are any problems.

macxcool commented on 2016-05-14 11:42 (UTC)

BTW, I've set: settings=~/.config/Docfetcher indexes=~/.cache/docfetcher swt=~/.local/share/docfetcher I thought those folders were appropriate. If you have an existing setup, you should close docfetcher, move stuff out of .docfetcher and then restart.

macxcool commented on 2016-05-14 11:39 (UTC)

OK. I'll get a .desktop file set up and update it today.

thiagowfx commented on 2016-05-13 17:45 (UTC)

I don't have time to edit it myself right now, but feel free to do so. My opinion on your questions: 1. Do what you think it's more intuitive / modern. 2. It's better we don't use git, to comply with the AUR guidelines. We could create a docfetcher-git package, it could indeed use git. However since this package is just 'docfetcher', we're better checking out a portable / release version. 3. Yeah, a .desktop file would be cool! And good work!

macxcool commented on 2016-05-12 11:31 (UTC)

OK. I have a few questions first, though: Should we leave the folders in paths.txt the same as before for the 6 people ;-) who use this? I changed them to more modern locations, but they were all in ~/.docfetcher before. Should we use a git checkout instead of the portable version. It should be more integrated with the system that way, including autostart etc. Also, do you want to create a .desktop file for this? Maybe the git version (we'd check out the release, not the dev. branch) has one. I'd have to check.

thiagowfx commented on 2016-05-12 02:52 (UTC)

Cool @macxcool! Can you update it? I just added you as co-maintainer.

macxcool commented on 2016-05-11 20:43 (UTC)

I've got a working PKGBUILD for you. How do you want it? Pastebin?

blixawillbargeld commented on 2016-03-01 09:50 (UTC)

Unfortunately I am not the right person to do PKGBUILDs, but would like to see this package maintained in the future!

thiagowfx commented on 2015-09-08 20:02 (UTC)

Anyone willing to co-maintain this package?