Hi Andreas,In README.md file they said:If you want to watch a directory for new files, first install:And then use (the output parameter has no effect, we output separate fasta files for each fast5 file):
- watchdog==0.8.3
OMP_NUM_THREADS=1 python basecall_no_metrichor.py --watch <directory name>watchdog version is fixed there but didn't test this feature with watchdog package in sid
or version 0.8.3 though.
Regards.
--2017-02-22 11:45 GMT+03:00 Andreas Tille <andreas@an3as.eu>:Hi Çağrı,
On Wed, Feb 22, 2017 at 01:45:56AM +0300, Çağrı ULAŞ wrote:
> I made some changes and will push them soon. Add manpages for scripts,
> changes in testsuite etc.
Sounds good.
I checked this and noticed you added "Suggests: watchdog". Do you have
any specific reason for this suggestion? I do not think that the fact
that calls to deepnano might take some time makes this suggestion
necessary specifically since some status update is given as output.
One hint for your debug code in run-test.sh: The sequence !! will be
interpreted by bash by he history function. I wrapped your debug line
into '' to prevent this.
> But when writing manpages, I realize that
> deepnano uses some files under nets_data/ in default arguments.
>
> in source code:
>
> parser.add_argument('--template_net', type=str, default="nets_data/map6temp. If upstream has a solution for [1] a quilt patch drawn from their
> npz")
> parser.add_argument('--complement_net', type=str, default=
> "nets_data/map6comp.npz")
> parser.add_argument('--big_net', type=str, default="nets_data/map6-2d-
> big.npz")
>
> these .npz files is python numpy saves. And I think, they use different
> reads
> according to this issue[1]. What can we do for this defaults? (Quilt patch?)
repository would be an apropriate solution. As far as I can see there
is no solution for the issue yet so what we can do is giving a hint
for the users of the Debian package in README.Debian.
In case you feel able to find a patch to solve this issue, yes, a quilt
patch would be an excelent solution and you should forward this patch to
the upstream tracker. This will be recieved as a very welcome
distribution from Debian to upstream and might give a good motivation
for upstream in case of further issues. Otherwise I do not think that
an open issue of upstream code should prevent us from releasing the
package since the test suite is running and seems to do something
sensible.
BTW, when checking for fresh commits I realised that my versioning which
should have matched the last commit data was wrong. I've fixed this.
> Are there anything else I can do for this program until we get a response
> from developer?
I do not think so. Usually new packages need to wait in the Debian new
queue for some time - if we are lucky upstream has fixed the issue
meanwhile and we can come up with a fix. So I'm tempted to upload the
package (after commenting out the debug code in run-test.sh) and if you
clarified your motivation for watchdog suggestion.
Please also inspect the latest changes I did:
1. Upstream does not provide a proper makefile and thus you added
the compilation lines in d/rules which is fine. I just added
$(CFLAGS) which was missing.
2. There was a lintian info about duplicated short description -
thus I've added (data) to the data package. Its a pretty minor
issue but simple to fix.
3. You ITPed the package (#844010)
Kind regards and thanks for your work on this
Andreas.
> [1] https://bitbucket.org/vboza/deepnano/issues/4/deepnano-with- metrichor-bad-input-argument
--
http://fam-tille.de
Çağrı ULAŞ