<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2017-09-18 22:49 GMT+02:00 Vojtech Kulvait <span dir="ltr"><<a href="mailto:kulvait@gmail.com" target="_blank">kulvait@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">HI all,<div>Andreas is correct that I was reverting changes in previous patches including mine, the reason was that initially I did not have fully patched tree. Now I am working on series of patches that will be clearer. Just let me to do this in a few days. I also agree to go through stretch-backports even if I consider this very conservative policy when current package in stretch is nonfunctional.</div><div><br></div><div>One thing which I come through when making dicompyler work is that it uses wxmpl.py file that is outdated. I think It would by wise to substitute it by the new release of that file from <a href="https://github.com/NOAA-ORR-ERD/wxmpl" target="_blank">https://github.com/NOAA-<wbr>ORR-ERD/wxmpl</a></div><div>What bothers me is the license. This file is released under MIT license, which should be OK. However even if the old file state</div><div><div class="gmail_extra"><div class="gmail_quote"># See the file "LICENSE" for information on usage and redistribution<div class="gmail_quote"># of this file, and for a DISCLAIMER OF ALL WARRANTIES.</div><div>the LICENSE file is not part of the dicompyler sources. So the question is how to give credit to wxmpl upstream developer. In this case I am into changing source tree and adding at least the <a href="https://github.com/NOAA-ORR-ERD/wxmpl/blob/master/LICENSE.txt" target="_blank">https://github.com/NOAA-<wbr>ORR-ERD/wxmpl/blob/master/<wbr>LICENSE.txt</a> file there.</div></div></div></div></div></blockquote><div>The license file is present and state usage of that part of software. Therefore everything is OK. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Best,</div><div>Vojtech.</div><div><div class="h5"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Vojtech,<br>
[please keep the bug in CC to make our discussion public.  There is no<br>
 point in discussing this privately.]<br>
<span class="m_-2724795027276222803gmail-"><br>
On Mon, Sep 18, 2017 at 03:41:06PM +0200, Vojtech Kulvait wrote:<br>
> I have successfully checked out the source from git as kulvait-guest. I<br>
> have also created my gpg keys, I am sending you my public key.<br>
<br>
</span>Fine. There is no need to send me the public key.  Just push it to the<br>
PGP mirrors and try to get some signatures from people you are meeting<br>
face to face.<br>
<span class="m_-2724795027276222803gmail-"><br>
> Build system really produces the directory egginfo.<br>
<br>
</span>Yes, it is produced.  But there is no harm done since pybuild is removing<br>
it again inside the build process.<br>
<span class="m_-2724795027276222803gmail-"><br>
> I don't know how to get<br>
> rid of this in the resulting package. However to spare git repository, it<br>
> is wise to create build directory outside source directory and call bulding<br>
> routines using<br>
> gbp buildpackage --git-export-dir=../dicompyler<wbr>_builddir<br>
> Using that git directory will not be affected. I think previously someone<br>
> called gbp buildpackage and then committed changes due to build to the git<br>
> repository.<br>
<br>
</span>Probably not - it was part of the upstream branch in Git.  Anyway, I<br>
think we have settled with this issue now since it is not there any<br>
more.<br>
<span class="m_-2724795027276222803gmail-"><br>
> Thank you very much for the patch you sent into git. There were however two<br>
> additional things to fix. First it was wrong indentation<br>
<br>
</span>Hmmm, according the wrong identantion this was introduced in your own<br>
previous patch.  I've fixed it there in another commit.  However, are<br>
you really sure you want to revert the previosly introduced matplotlib<br>
compatibility conditionals?  What is wrong in<br>
<br>
     if matplotlib.__version__ > '1.2':<br>
         grid = mpl_Path(contour).contains_poi<wbr>nts(dosegridpoints)<br>
     else:<br>
         grid = nx.points_inside_poly(dosegrid<wbr>points, contour)</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
which was introduced in patch enable_later_versions_of_matpl<wbr>otlib.patch<br>
and reverted by you later?  Probably we should rather fix it in the<br>
initial patch and not do patch reversals later.  This will lead to<br>
confusion.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="m_-2724795027276222803gmail-"><br>
> and second it was<br>
> incompatibility with pillow >= 3.0.0. I fixed this and added the new patch<br>
> (01.patch). Now it is possible to explore RT data. With the new patch, the<br>
> package is finally functional and I suggest propagating current change into<br>
> stretch.<br>
<br>
</span>We can not simply move this to stretch since this is now released.  We<br>
can upload to unstable for now and once it is error free there we can<br>
upload to stretch-backports.<br>
<span class="m_-2724795027276222803gmail-"><br>
> I have not made changes to changelog since I don't know how. If I increase<br>
> release number and add the following to changelog<br>
> dicompyler (0.4.2.0-2) UNRELEASED; urgency=high<br>
><br>
>   * Works with pillow >=3.0.0 addressing changes due to commit<br>
> <a href="https://github.com/python-pillow/Pillow/commit/71c95c8e5f3bba1845444a246d04646825e6bab3" rel="noreferrer" target="_blank">https://github.com/python-pill<wbr>ow/Pillow/commit/71c95c8e5f3bb<wbr>a1845444a246d04646825e6bab3</a><br>
> .<br>
>   * Indentation fix<br>
><br>
>  -- Vojtěch Kulvait <<a href="mailto:kulvait@gmail.com" target="_blank">kulvait@gmail.com</a>>  Mon, Sep 18 15:21:26 CEST 2017<br>
> It complains that<br>
> W: dicompyler source: changelog-should-mention-nmu<br>
> W: dicompyler source: source-nmu-has-incorrect-versi<wbr>on-number 0.4.2.0-2<br>
<br>
</span>That's because you are not yet mentioned in debian/control as Uploader.<br>
Feel free to add yourself there!<br>
Alternatively add a line<br>
<br>
  * Team upload<br>
<br>
to silence lintian.<br>
<span class="m_-2724795027276222803gmail-"><br>
> W: dicompyler source: newer-standards-version 4.1.0 (current is 3.9.8)<br>
<br>
</span>Feel free to ignore this (or better use lintian from unstable).<br>
<span class="m_-2724795027276222803gmail-"><br>
> W: dicompyler: syntax-error-in-debian-changel<wbr>og line 6 "badly formatted<br>
> trailer line"<br>
> W: dicompyler: syntax-error-in-debian-changel<wbr>og line 9 "found start of<br>
> entry where expected more change data or trailer"<br>
> W: dicompyler: debian-changelog-line-too-long line 3<br>
<br>
</span>That's due to your indentation mistake.  There is no need to<br>
put the full URL there if it is just inside the patch.<br>
<span class="m_-2724795027276222803gmail-"><br>
> gpg: /tmp/debsign.I7Bhm81m/dicompyl<wbr>er_0.4.2.0-2.dsc: clear-sign failed: No<br>
> secret key<br>
><br>
> I am probably not allowed to increase even minor release num?<br>
<br>
</span>No, you are - but it would be wrong anyway since 0.4.2.0-1 is UNRELEASED<br>
yet - so please just leave the -1 and add your changes there.  (It even<br>
has the suggested "Team upload" line!)  Simply use<br>
<br>
   dch<br>
<br>
to add your changes.<br>
<span class="m_-2724795027276222803gmail-"><br>
> I suggest<br>
> increasing urgency to high or even emergency to really stress that this<br>
> version is functional.<br>
<br>
</span>Per policy there is no reason to bump urgency.  This is a normal upload<br>
to unstable.  As I explain we can NOT upload to stretch.  The only<br>
chance to upload to stretch is if there are *security* relevant bugs.<br>
So we need to go via stretch backports.<br>
<span class="m_-2724795027276222803gmail-"><br>
> I think however one thing is left to do which is to allow visualization of<br>
> the structures drawn to RT data, I will try to work on that.<br>
<br>
</span>Fine.  What about becoming upstream and create a new release?<br>
<span class="m_-2724795027276222803gmail-"><br>
> Another task I can eventually look at is to explore upstream branch by the<br>
> dicompyler author<br>
> <a href="https://github.com/bastula/dicompyler/tree/dependencyupdate" rel="noreferrer" target="_blank">https://github.com/bastula/dic<wbr>ompyler/tree/dependencyupdate</a> however if he<br>
> claim that it was not tested on linux or with python3 it will probably not<br>
> be as important.<br>
><br>
> As you suggested I can fork dicompyler on github and make the changes<br>
> (probably including other debian patches if reasonable) public and<br>
> eventually make pull request to upstream author. But first lets package<br>
> functional debian package :)<br>
<br>
</span>I'm fine with this.  As I said above please reconsider the matplotlib<br>
change and afterwards I can upload as is while you can take your time<br>
for other changes later.<br>
<br>
Kind regards<br>
<span class="m_-2724795027276222803gmail-HOEnZb"><font color="#888888"><br>
      Andreas.<br>
<br>
--<br>
<a href="http://fam-tille.de" rel="noreferrer" target="_blank">http://fam-tille.de</a><br>
</font></span></blockquote></div></div></div><br></div></div></div>
</blockquote></div><br></div></div>