Skip Menu |

This queue is for tickets about the File-Locate CPAN distribution.

Report information
The Basics
Id: 27712
Status: open
Priority: 0/
Queue: File-Locate

People
Owner: VPARSEVAL [...] cpan.org
Requestors: emmet [...] netrogen.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Broken on Ubuntu Feisty x86_64
Date: Sun, 24 Jun 2007 05:35:31 -0400
To: bug-File-Locate [...] rt.cpan.org
From: Emmet Caulfield <emmet [...] netrogen.com>
Hi, File::Locate (0.62 from CPAN, all tests pass) is broken on Ubuntu Feisty x86_64. It simply returns nothing, but "does something" since there is a noticeable delay, similar to what one would expect for slocate running the same search, before no output occurs. After encountering the problem running I added myself to the 'slocate' group so I could access slocate's database without any messing around (i.e. using 'sudo'). Using 'sudo' doesn't help :( Diagnostic and demonstration commands follow. HTH, Emmet. $ uname -a Linux scrat 2.6.20-16-generic #2 SMP Thu Jun 7 19:00:28 UTC 2007 x86_64 GNU/Linux $ perl --version | grep ^This This is perl, v5.8.8 built for x86_64-linux-gnu-thread-multi $ perl -MFile::Locate -e 'print "$File::Locate::VERSION\n"' 0.62 $ export LOCATE_PATH='/var/lib/slocate/slocate.db' $ locate .mp3 | wc -l 857 $ locate .mp3 | head -n+1 /home/emmet/Desktop/GVRProject/anim/flight.mp3 $ perl -MFile::Locate -e 'print locate ".mp3"' (delay, then no output)
Hi Emmet, took me a few days to read this message as I started migrating my Linux from one distribution to another last weekend. But luckily for you the new distribution is Feisty and my hardware is x86_64, so this should be easy to analyse though I'll have to fix some other things on my machine first. You'll read further feedback (hopefully about a new version ;-) within the next 18 days. Regards, Thomas
OK, my last comment was hasty (nothing of an Ent in me ;-), I thought this ticket refered to an old version of File::CachingFind (which started existance as File::Locate before getting a more appropriate name). CPAN still had stored me as maintainer (which I changed a few minutes ago transfering prime-maintainership to Tassilo von Parseval). So a sorry from me, that's not my module - I just can pass on the ticket (and hope that rt-cpan does the right thing with it).
Subject: Re: [rt.cpan.org #27712] Broken on Ubuntu Feisty x86_64
Date: Thu, 26 Jul 2007 06:33:53 -0400
To: bug-File-Locate [...] rt.cpan.org
From: Tassilo von Parseval <tassilo.von.parseval [...] rwth-aachen.de>
Hi there, On Jun 24, 2007, at 5:35 AM, Emmet Caulfield via RT wrote: Show quoted text
> File::Locate (0.62 from CPAN, all tests pass) is broken on Ubuntu > Feisty x86_64. It simply returns nothing, but "does something" since > there is a noticeable delay, similar to what one would expect for > slocate running the same search, before no output occurs. > > After encountering the problem running I added myself to the 'slocate' > group so I could access slocate's database without any messing around > (i.e. using 'sudo'). Using 'sudo' doesn't help :( > > Diagnostic and demonstration commands follow.
Hmmh, I can't really say what's going on here. The fact that the tests pass might not mean anything. Were you running the tests as root? If not, the slocate tests kind of trivially succeed because otherwise it would check for the file access mode of each entry found in the test slocate DB that I created on my machine. Can you do a 'make test' as root? Show quoted text
> HTH, > > Emmet. > > $ uname -a > Linux scrat 2.6.20-16-generic #2 SMP Thu Jun 7 19:00:28 UTC 2007 > x86_64 GNU/Linux > $ perl --version | grep ^This > This is perl, v5.8.8 built for x86_64-linux-gnu-thread-multi > $ perl -MFile::Locate -e 'print "$File::Locate::VERSION\n"' > 0.62 > $ export LOCATE_PATH='/var/lib/slocate/slocate.db' > $ locate .mp3 | wc -l > 857 > $ locate .mp3 | head -n+1 > /home/emmet/Desktop/GVRProject/anim/flight.mp3 > $ perl -MFile::Locate -e 'print locate ".mp3"' > (delay, then no output)
What would help me is if you ran that command under 'trace' and pasted some bits of that output here. Specifically, are there any calls to access (1) and if so, what is their return value? Cheers, Tassilo