Bug#845155: RFS: rmlint/2.4.4
Control: rititle -1 ITP: rmlint -- file reduplication toolset
Control: owner -1 !
Hi Chris,
I intend to package your project for Debian, and almost have a complete
working solution.
My problem is when I try to build the package with sbuild (i.e. from
inside a clean chroot),
the nose tests never complete. Perhaps they eventually would, but I'm
not prepared
to wait that long. I have so far left it for a few hours. Building the
package the normal way
on my Debian box, works however, and the tests don't take too long at all.
I've had a read of docs/testing.rst, but still can't figure out what
could be causing the problem.
The slow tests are already omitted, since the test command being used is:
nosetests3 -s -v -a '!slow'
i.e. without sudo.
And as far as I know, only /dev/shm from within the chroot uses tmpfs.
The underlying
filesystem being used by the chroot is ext4.
I've also tried setting RM_TS_DIR (i.e. changed from
/tmp/rmlint-unit-testdir to
/build/rmlint-unit-testdir), but got the same result. I can't tell you
which tests get to complete,
because nothing is output when using sbuild, even with
RM_TS_PRINT_CMD=1. The tests
do get printed out in a normal build however. The following are the only
files that are created
inside RM_TS_DIR if it is of any help:
drwxrwsr-x 2 carlos sbuild 4096 Jan 15 02:25 .
drwxrws--- 21 sbuild sbuild 4096 Jan 15 02:25 ..
-rw-rw-r-- 1 carlos sbuild 4 Jan 15 02:25 a
-rw-rw-r-- 1 carlos sbuild 4 Jan 15 02:25 b
-rw-rw-r-- 1 carlos sbuild 0 Jan 15 02:25 .csv-0
-rw-rw-r-- 1 carlos sbuild 4 Jan 15 02:25 stupid'file,name
The only other RM_TS variable I've set so far is RM_TS_PEDANTIC which
I've set to 0.
Do the tests only work in virtualized environments, but not chroot?
Perhaps the only
solution would be to disable the tests completely in a chroot.
Cheers,
Carlos
On Sun, 20 Nov 2016 22:12:30 +0100 Christopher Pahl wrote:
> Package: sponsorship-requests
> Severity: normal
>
> Hello.
>
> I'm the developer of rmlint (https://github.com/sahib/rmlint), a file
deduplication toolset.
> It tries to be more useful (helps in actually deleting the found
duplicate data),
> faster (something between 5x and 30x) and better tested than the
popular fdupes.
> Additionally an optional GUI written in Python is included.
>
> Since I'm not a Debian myself user myself, I have a hard time bringing
the software
> into Debian, although I know (from bug reports and IRC) that many
users of Debian based distributions
> compile it from source. I tried to persuade Axel Beckert
(https://wiki.debian.org/XTaran) to sponsor
> it, but he seems to a bit too busy. He did provide a basic packaging
effort though, which can be found here:
>
> https://github.com/sahib/rmlint/pull/180 (does not include the GUI,
should be probably a separate package)
>
> In short: I'm looking for a sponsor *and* maintainer (which do not
need to be the same person).
> Optimally the maintainer would be someone that uses rmlint from time
to time.
> The package already builds the cli and might only need minimal review.
>
> Sorry if this is not the right place to ask - I'm just a bit desparate
since most other distributions
> already ship rmlint. It's not that there aren't any volunteers, most
of them just fail on the relative high
> hurdle to bring a package into Debian.
>
> Best regards,
> Chris Pahl
>
> -- System Information (this is a VM, due to reportbug):
> Debian Release: 8.4
> APT prefers stable
> APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
>
Reply to: