<div dir="ltr"><div>Hi Bas,</div><div><br></div><div>at the moment I do not have good sandbox for playing with packaging. But I have checked the source package of mapproxy_1.11.0-3 (Debian Buster apt).<br></div><div><br></div><div>As I have not tested it and I just read it and checked on my filesystem I get feeling, that something is going wrong during packaging. Looks like the debain/rules do some tweaks, move files and create symlinks and uses ../python3.7/... names. Than probably something (or task of dh) renames .../python3.7/... to .../python3/...</div><div><br></div><div>I am not good in package maintenance and do not know the correct sequence it executes during packaging.</div><div><br></div><div>I have the possible explanation, what happens:</div><div><br></div><div>For me it looks like, it moves /templates/ from /usr/lib/python3.7/dist-packages into /usr/share/python3-mapproxy and creates broken link in /usr/lib/python3.7/dist-packages pointing to (system) /usr/lib/python3.7/dist-packages (I expect that the file is missing on building machine, so it is broken link). Later dh (or whatever it is) task which corrects it, it ignores broken links so it will not fix it, and those broken links remains and for example on my system I see those links really in
/usr/lib/python3.7/dist-packages/mapproxy/...</div><div><br></div><div>But as I noticed, I have not tested it, and I do not fully understand to packaging sequences and tools, so it is only my feeling.</div><div><br></div><div>Why I get this feeling:</div><div><br></div><div>Check mapproxy-1.11.0/debian/rules, block override_dh_auto_install and inside this block to following part:</div><div><br></div><div> for V in `py3versions -v -s`; do \<br> for F in DejaVuSans.ttf DejaVuSansMono.ttf; do \<br> $(RM) debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/image/fonts/$$F ; \<br> ln -s /usr/share/fonts/truetype/dejavu/$$F \<br> debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/image/fonts/$$F ; \<br> done ; \<br> if [ ! -e debian/python3-$(PYBUILD_NAME)/usr/share/python3-$(PYBUILD_NAME)/service/templates ]; then \<br> mkdir -p debian/python3-$(PYBUILD_NAME)/usr/share/python3-$(PYBUILD_NAME)/service ; \<br> mv debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/service/templates \<br> debian/python3-$(PYBUILD_NAME)/usr/share/python3-$(PYBUILD_NAME)/service/ ; \<br> else \<br> $(RM) -r debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/service/templates ; \<br> fi ; \<br> ln -s /usr/share/python3-$(PYBUILD_NAME)/service/templates \<br> debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/service/templates ; \<br> if [ ! -e debian/python3-$(PYBUILD_NAME)/usr/share/python3-$(PYBUILD_NAME)/test/schemas ]; then \<br> mkdir -p debian/python3-$(PYBUILD_NAME)/usr/share/python3-$(PYBUILD_NAME)/test ; \<br> mv debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/test/schemas \<br> debian/python3-$(PYBUILD_NAME)/usr/share/python3-$(PYBUILD_NAME)/test/ ; \<br> else \<br> $(RM) -r debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/test/schemas ; \<br> fi ; \<br> ln -s /usr/share/python3-$(PYBUILD_NAME)/test/schemas \<br> debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/test/schemas ; \<br> if [ ! -e debian/python3-$(PYBUILD_NAME)/usr/share/python3-$(PYBUILD_NAME)/test/system/fixture/cache_data ]; then \<br> mkdir -p debian/python3-$(PYBUILD_NAME)/usr/share/python3-$(PYBUILD_NAME)/test/system/fixture ; \<br> mv debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/test/system/fixture/cache_data \<br> debian/python3-$(PYBUILD_NAME)/usr/share/python3-$(PYBUILD_NAME)/test/system/fixture/ ; \<br> else \<br> $(RM) -r debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/test/system/fixture/cache_data ; \<br> fi ; \<br> ln -s /usr/share/python3-$(PYBUILD_NAME)/test/system/fixture/cache_data \<br> debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/test/system/fixture/cache_data ; \<br> done</div><div><br></div><div>For me it looks like it move templates from
debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/service/templates into debian/python3-$(PYBUILD_NAME)/usr/share/python3-$(PYBUILD_NAME)/service/templates, but it creates symlink debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/service/templates pointing to system path
/usr/share/python3-$(PYBUILD_NAME)/service/templates instead expected debian/usr/share/python3-$(PYBUILD_NAME)/service/templates, so debian is missing at the beginning ($(PYBUILD_NAME)=mapproxy, $$V=3.7 (result of py3versions -v -s)).</div><div><br></div><div>During build time it creates broken symlink, as system path
/usr/share/python3-$(PYBUILD_NAME)/service/templates does not exists at the build time.</div><div><br></div><div>Same bug is in python2.7 part, but in this case /usr/lib/python2.7 is not renamed into something else, and if on building system is already installed older package, than the link is created to existing system files, so later "dh" task (or what ever it is) correctly do it.</div><div><br></div><div>
<div>For me it is possible explanation, why it works for font links and python2.7 and
not works for the python3 other links. But again, do not fully understand
packaging, so it is only my guess. My feeling is, that there is missing debian/ in front of link paths.<br></div><div><br></div>
</div><div>For the issue with capabilities I prepared patch python3.7-capabilities.patch I attached. This patch can be included into patches and patches/series.</div><div><br></div><div>Everything I am writing is about stable package from Debian Buster.</div><div><br></div><div>Explanation why I use Python 3.7 instead of 2.7. Since Debian Buster I used only Python 2.7. For me Debian release is like milestone in my computer life, so for example with Buster I changed:</div><div><br></div><div>iptables > nftables</div><div>python-2.7 > python-3.7</div><div><br></div><div>I already rewrite almost all my own python scripts and tools into Python 3.7 and using libapache2-mod-wsgi-py3.</div><div><br></div><div>For me it is more like personal choice, than rational choice, meaning switching to Python 3.7. I am fine to patch only my package using dpkg-deb tool every time you release new package version. After today's experience and investigation I have lot of notes. :-)</div><div><br></div><div>You can close the ticket if you want, as Python 2.7 version works.</div><div><br></div><div>And one more tip: I saw in
debian/mapproxy.links:</div><div>usr/lib/python-mapproxy/mapproxy-seed usr/bin/mapproxy-seed<br>usr/lib/python-mapproxy/mapproxy-util usr/bin/mapproxy-util</div><div><br></div><div>It will be very useful for those using Python 3 to add:</div><div>usr/lib/python3-mapproxy/mapproxy-seed usr/bin/mapproxy-seed<br>usr/lib/python3-mapproxy/mapproxy-util usr/bin/mapproxy-util<br></div><div></div><div><br></div><div>Best regards,</div><div><br></div><div>Marek<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 27, 2019 at 6:25 PM Sebastiaan Couwenberg <<a href="mailto:sebastic@xs4all.nl">sebastic@xs4all.nl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Control: tags -1 - moreinfo<br>
Control: severity -1 important<br>
<br>
I've installed mapproxy on a test server with stretch, it contains the<br>
symlinks as well:<br>
<br>
# find /usr/lib/python2.7/dist-packages/mapproxy/ -type l -exec ls -l {} \;<br>
lrwxrwxrwx 1 root root 73 Jan 7 2018<br>
/usr/lib/python2.7/dist-packages/mapproxy/test/system/fixture/cache_data<br>
-> ../../../../../../../share/python-mapproxy/test/system/fixture/cache_data<br>
lrwxrwxrwx 1 root root 49 Jan 7 2018<br>
/usr/lib/python2.7/dist-packages/mapproxy/test/schemas -><br>
../../../../../share/python-mapproxy/test/schemas<br>
lrwxrwxrwx 1 root root 54 Jan 7 2018<br>
/usr/lib/python2.7/dist-packages/mapproxy/service/templates -><br>
../../../../../share/python-mapproxy/service/templates<br>
lrwxrwxrwx 1 root root 60 Jan 7 2018<br>
/usr/lib/python2.7/dist-packages/mapproxy/image/fonts/DejaVuSans.ttf -><br>
../../../../../../share/fonts/truetype/dejavu/DejaVuSans.ttf<br>
lrwxrwxrwx 1 root root 64 Jan 7 2018<br>
/usr/lib/python2.7/dist-packages/mapproxy/image/fonts/DejaVuSansMono.ttf<br>
-> ../../../../../../share/fonts/truetype/dejavu/DejaVuSansMono.ttf<br>
<br>
It as successfully serves the demo with your mapproxy.yaml, both the PNG<br>
& Capabilities document.<br>
<br>
After the upgrade to buster, the demo still works when using the default<br>
python2.7 packages, python-mapproxy also contains the symlinks:<br>
<br>
# find /usr/lib/python2.7/dist-packages/mapproxy/ -type l -exec ls -l {} \;<br>
lrwxrwxrwx 1 root root 73 Jan 7 2018<br>
/usr/lib/python2.7/dist-packages/mapproxy/test/system/fixture/cache_data<br>
-> ../../../../../../../share/python-mapproxy/test/system/fixture/cache_data<br>
lrwxrwxrwx 1 root root 49 Jan 7 2018<br>
/usr/lib/python2.7/dist-packages/mapproxy/test/schemas -><br>
../../../../../share/python-mapproxy/test/schemas<br>
lrwxrwxrwx 1 root root 54 Jan 7 2018<br>
/usr/lib/python2.7/dist-packages/mapproxy/service/templates -><br>
../../../../../share/python-mapproxy/service/templates<br>
lrwxrwxrwx 1 root root 60 Jul 31 2018<br>
/usr/lib/python2.7/dist-packages/mapproxy/image/fonts/DejaVuSans.ttf -><br>
../../../../../../share/fonts/truetype/dejavu/DejaVuSans.ttf<br>
lrwxrwxrwx 1 root root 64 Jul 31 2018<br>
/usr/lib/python2.7/dist-packages/mapproxy/image/fonts/DejaVuSansMono.ttf<br>
-> ../../../../../../share/fonts/truetype/dejavu/DejaVuSansMono.ttf<br>
<br>
python3-mapproxy indeed does not:<br>
<br>
# find /usr/lib/python3/dist-packages/mapproxy/ -type l -exec ls -l {} \;<br>
lrwxrwxrwx 1 root root 60 Jul 31 2018<br>
/usr/lib/python3/dist-packages/mapproxy/image/fonts/DejaVuSans.ttf -><br>
../../../../../../share/fonts/truetype/dejavu/DejaVuSans.ttf<br>
lrwxrwxrwx 1 root root 64 Jul 31 2018<br>
/usr/lib/python3/dist-packages/mapproxy/image/fonts/DejaVuSansMono.ttf<br>
-> ../../../../../../share/fonts/truetype/dejavu/DejaVuSansMono.ttf<br>
<br>
And hence also cannot run the demo successfully.<br>
<br>
I've downgraded the severity of this issue since the defaults still work.<br>
<br>
While mapproxy 1.11.1 doesn't contain any related changes, it does<br>
successfully serve the PNG with Python 3 on bullseye (testing). It fails<br>
with an internal error for the Capabilities document:<br>
<br>
TypeError: Extra position arguments: True at line 169 column 3 in file<br>
/usr/lib/python3/dist-packages/mapproxy/service/templates/wms111capabilities.xml<br>
<br>
I'll fix this first in unstable by cherry-picking the commit.<br>
<br>
Do you really need to run mapproxy with Python 3 on buster?<br>
<br>
If not, we can leave the package as it, just use python-mapproxy on<br>
buster (which is installed as a dependency of the mapproxy package).<br>
<br>
Otherwise I'll need to prepare a stable update with the commit for the<br>
TypeError and find a fix for the missing symlinks in the python3 package.<br>
<br>
Kind Regards,<br>
<br>
Bas<br>
<br>
-- <br>
GPG Key ID: 4096R/6750F10AE88D4AF1<br>
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1<br>
</blockquote></div>