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) > >