Re: django-pipeline / slimit

[Brian May]

Raphael Hertzog  writes:

> Yeah, skip the test on Python 3, tell upstream that slimit is not
> supported on Python 3 and that the test should be skipped there.

Upstream pipeline seem to think slimit works fine with Python 3:
https://github.com/jazzband/django-pipeline/issues/554#issuecomment-200842866

Maybe I should have a look at doing the python-slimit and python3-slimit
split again.
-- 
Brian May 

Re: Packaging dependencies for mailman3-hyperkitty

[Paul Wise]

On Fri, 2016-03-25 at 19:35 +0100, Pierre-Elliott Bécue wrote:

> That's in progress, the only goal of this detection is to deactivate
> javascript dynamic load of threads. We're thinking about alternative
> solutions.

I don't understand why you would deactivate JavaScript dynamic load for
bots? Typically they don't support JavaScript (except Google) and you
should have a fallback for people who turn off JavaScript anyway.

I hope mailman3/HyperKitty web interfaces use progressive enhancement:

http://en.wikipedia.org/wiki/Progressive_enhancement

> I understand your point, and I'll think about it, but my goal is to make
> upstream remove obsolete dependencies. django-libravatar seems to be the
> only project that bundles support for that, and it's not maintained, whereas
> django-gravatar2 is still maintained.

I guess you are talking about this project, it hasn't seen any issues
filed so probably just works as-is without needing any changes?

https://github.com/fnp/django-libravatar

> So, for now, I think that I'd rather have a first mailman3 suite in debian,
> and then, think about how to make things better. :)

I see.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




signature.asc
Description: This is a digitally signed message part

Re: running tests against installed version of package

[Ben Finney]

Brian May  writes:

> Ben Finney  writes:
>
> > As another check, you can test the resulting URL with a ‘git clone’ to a
> > temporary target directory.
>
> It doesn't seem to like me today:

Alioth is not responding at all, for me at the moment. And not just for me:



You'll need to do the test when Alioth can actually pass the test :-)

-- 
 \  “If you were going to shoot a mime, would you use a silencer?” |
  `\—Steven Wright |
_o__)  |
Ben Finney

Re: running tests against installed version of package

[Brian May]

Ben Finney  writes:

> As another check, you can test the resulting URL with a ‘git clone’ to a
> temporary target directory.

It doesn't seem to like me today:

% git clone 
https://anonscm.debian.org/git/python-modules/packages/apscheduler.git
Cloning into 'apscheduler'...
[ relatively long timeout ]
fatal: unable to access 
'https://anonscm.debian.org/git/python-modules/packages/apscheduler.git/': 
gnutls_handshake() failed: Error in the pull function.

Is this URL correct?

I also tried git from unstable in case the version in Jessie is broken,
however the results are the same
-- 
Brian May 

Re: running tests against installed version of package

[Ben Finney]

Brian May  writes:

> Ben Finney  writes:
>
> > The “git:” URL method is not encrypted. You should specify the encrypted
> > “https:” method in the “VCS-Git” field
>
> So just to double check, this should solve that right?
>
> sed 's=git://anonscm.debian.org/=https://anonscm.debian.org/git/=' 
> */debian/control

That looks right to me, for the case you presented. I make no promises
for what will result on other texts :-)

> ...I notice a number of packages I maintain have this problem and I
> really want to make sure I get this right first time!

As another check, you can test the resulting URL with a ‘git clone’ to a
temporary target directory.

-- 
 \ “A child of five could understand this. Fetch me a child of |
  `\  five.” —Groucho Marx |
_o__)  |
Ben Finney

Re: running tests against installed version of package

[Brian May]

Ben Finney  writes:

> The “git:” URL method is not encrypted. You should specify the encrypted
> “https:” method in the “VCS-Git” field:
>
> Vcs-Git:
> https://anonscm.debian.org/git/python-modules/packages/apscheduler.git

So just to double check, this should solve that right?

sed 's=git://anonscm.debian.org/=https://anonscm.debian.org/git/=' 
*/debian/control

...I notice a number of packages I maintain have this problem and I
really want to make sure I get this right first time!
-- 
Brian May 

Re: Packaging pythonpy

[Tiago Ilieve]

Gianfranco,

On 25 March 2016 at 19:07, Gianfranco Costamagna
 wrote:
> up to your sponsor :)

Tried one or two new approaches and it didn't worked. In the I've
created a patch[1] changing "#!/usr/bin/env python2" to
"#!/usr/bin/env python". This should work as long as Python 2 is the
default interpreter, something which may change in the next years, but
isn't a problem at least for Stretch.

I'm all in for another options if someone doesn't like this patch.

> swap Files: debian/*
> and Files: *
>
> first the more comprehensive and later the less.
> (lintian might be more specific)

This is awesome. I would never figure out by myself that it was so
simple to fix. :-)

> I did fix the python apps in blah section with section "utils", and uploaded 
> on debomatic again.
> Now that lintian warning is not there anymore.

Yup. I've did that as well[2].

> (I won't download the package, I think I already answered the points)

No problem. You answers were very helpful, as always.

I've uploaded a new version of the package to mentors.d.n[3]. There
are the following lintian messages now:

* "newer-standards-version": which can be ignored, as mentors.d.n
doesn't consider 3.9.7 as the current standard.
* "debian-watch-file-is-missing" and "no-upstream-changelog": which
will be fixed in the near future with upstream help regarding tagged
releases.
* "binary-without-manpage": which I'll be fixing, adding a manpage
before submitting an RFS.

Thank you very much, Gianfranco!

Regards,
Tiago.

[1]: https://github.com/myhro/deb-pythonpy/commit/5450656
[2]: https://github.com/myhro/deb-pythonpy/commit/0e2d987
[3]: http://mentors.debian.net/package/pythonpy

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Packaging pythonpy

[Gianfranco Costamagna]

Hi,
>I really appreciate your effort in trying to package it yourself, but

>you didn't solved the main problem, which is the
>"python-script-but-no-python-dep".


indeed, control file line two.

it is an application, so choose some Section from there
https://qa.debian.org/developer.php?login=python-apps-team%40lists.alioth.debian.org

Section: python is for libraries (e.g. called python-foo or python3-foo)


>The "dh_auto_install" override is used to place it in>"/usr/share/pythonpy" 
>which is the proper place for Python
>*applications*[1]. Without it, it goes to the place where *libraries*
>should be located.


ok
>The "remove_entry_points_scripts.patch" avoids the creation of
>py{2,2.7} binaries that aren't needed. Without it and removing the
>override for "dh_fixperms", the package becomes useless. There's no
>way to call the "py" command, as its main script doesn't have
>execution permissions.


ok, but why some of them have the +x set?
http://debomatic-amd64.debian.net/distribution#unstable/pythonpy/0.4.4-1/contents

I wouls suggest patching the setup file to perform correctly instead of 
overriding stuff.

>Looks like it would be way easier to fix the entry point scripts to
>created a binary named "py", avoiding just the other ones. We can also
>ignore the override that changes the target folder, but doing this
>feels wrong, is like we are ignoring the best practices for packaging
>Python applications. That's why I'm wrecking my head with this issue,
>removing every file that would be useless, instead of following the
>easiest path.


up to your sponsor :)

>About the lintian output:



>* "unused-file-paragraph-in-dep5-copyright": this info doesn't appear
>even when I run lintian with the same arguments on my machine. This is
>strange, as I'm running "v2.5.42.1" from sid and debomatic-amd64.d.n
>is using "v2.5.42.1~bpo8+1", which should be the same version. Do you
>know how can I do this?


swap Files: debian/*
and Files: *

first the more comprehensive and later the less.
(lintian might be more specific)


>* "debian-watch-file-is-missing": this is right. I've asked[2]>upstream to tag 
>every release on GitHub, so we can fetch information
>about new versions from there.
>* "application-in-library-section": fixed[3].
>* "no-upstream-changelog": the upstream added a changelog file in the
>last version (0.4.9, which I have packaged this afternoon), but it
>doesn't comes with the tarball available in PyPI. This will be solved
>when the releases are tagged and we grab them from GitHub.
>* "package-installs-into-obsolete-dir": fixed using dh_bash-completion[4].
>
>I've uploaded the last (0.4.9-1) package version to mentors.d.n[5].


I did fix the python apps in blah section with section "utils", and uploaded on 
debomatic again.

Now that lintian warning is not there anymore.


(I won't download the package, I think I already answered the points)

cheers,

G.

Re: running tests against installed version of package

[Barry Warsaw]

On Mar 25, 2016, at 06:17 PM, Brian May wrote:

>However I have a package where the tests require the entry points from
>setup.py to be configured, the tests fail without this.
>
>So what is the appropriate way to modify debian/rules to get the tests
>to run from the installed version with the entry points available?

In some cases, I've just taken to adding DEP-8 tests for those.

Cheers,
-Barry

Re: Packaging pythonpy

[Tiago Ilieve]

Hi Gianfranco,

On 25 March 2016 at 16:21, Gianfranco Costamagna
 wrote:
> http://debomatic-amd64.debian.net/distribution#unstable/pythonpy/0.4.4-1/lintian
> please dget it from there and start again :)
>
> I fixed a lot of issues, and many more are there now!

I really appreciate your effort in trying to package it yourself, but
you didn't solved the main problem, which is the
"python-script-but-no-python-dep".

The "dh_auto_install" override is used to place it in
"/usr/share/pythonpy" which is the proper place for Python
*applications*[1]. Without it, it goes to the place where *libraries*
should be located.

The "remove_entry_points_scripts.patch" avoids the creation of
py{2,2.7} binaries that aren't needed. Without it and removing the
override for "dh_fixperms", the package becomes useless. There's no
way to call the "py" command, as its main script doesn't have
execution permissions.

Looks like it would be way easier to fix the entry point scripts to
created a binary named "py", avoiding just the other ones. We can also
ignore the override that changes the target folder, but doing this
feels wrong, is like we are ignoring the best practices for packaging
Python applications. That's why I'm wrecking my head with this issue,
removing every file that would be useless, instead of following the
easiest path.

About the lintian output:

* "unused-file-paragraph-in-dep5-copyright": this info doesn't appear
even when I run lintian with the same arguments on my machine. This is
strange, as I'm running "v2.5.42.1" from sid and debomatic-amd64.d.n
is using "v2.5.42.1~bpo8+1", which should be the same version. Do you
know how can I do this?
* "debian-watch-file-is-missing": this is right. I've asked[2]
upstream to tag every release on GitHub, so we can fetch information
about new versions from there.
* "application-in-library-section": fixed[3].
* "no-upstream-changelog": the upstream added a changelog file in the
last version (0.4.9, which I have packaged this afternoon), but it
doesn't comes with the tarball available in PyPI. This will be solved
when the releases are tagged and we grab them from GitHub.
* "package-installs-into-obsolete-dir": fixed using dh_bash-completion[4].

I've uploaded the last (0.4.9-1) package version to mentors.d.n[5].

Thanks,
Tiago.

[1]: https://wiki.debian.org/Python/Packaging#Example_2:_Python_application
[2]: https://github.com/Russell91/pythonpy/issues/76
[3]: https://github.com/myhro/deb-pythonpy/commit/0e2d987
[4]: https://github.com/myhro/deb-pythonpy/commit/954e424
[5]: http://mentors.debian.net/package/pythonpy

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Packaging dependencies for mailman3-hyperkitty

[Pierre-Elliott Bécue]

Le vendredi 25 mars 2016 à 13:02:55+0800, Paul Wise a écrit :
> On Thu, Mar 24, 2016 at 11:43 PM, Pierre-Elliott Bécue wrote:
> 
> > Packaging dependencies for mailman3-hyperkitty
> 
> Does HyperKitty depend on mailman3 or just enhance it by providing an
> archive web interface? If the latter, I would suggest calling it
> hyperkitty instead of mailman3-hyperkitty.
> 
> > robot-detection suffers the same illness, but it's tiny, it's possible to
> > integrate it in hyperkitty, or make it optionnal.
> 
> Embedded code copies are against Debian policy, please package it
> separately or get upstream to switch to something else.
> 
> https://wiki.debian.org/EmbeddedCodeCopies
> 
> Something like that sounds like it isn't possible to keep usefully
> up-to-date in Debian stable though, since the landscape of robots on
> the web will be changing continually and many will be aiming to
> emulate browsers.
> 
> https://pypi.python.org/pypi/robot-detection
> 
> In addition, it seems to be woefully inadequate for that since the API
> doesn't appear to take into account IP address ranges.
> 
> It also depends on the robotstxt.org database, which would need to be
> packaged separately and is also no longer kept up to date at this
> time:
> 
> http://www.robotstxt.org/db.html
> 
> "This robots database is currently undergoing re-engineering. Due to
> popular demand we have restored the existing data, but
> addition/modification are disabled."
> 
> As the page says, there is a better database of user-agents available
> 
> http://www.botsvsbrowsers.com/
> http://www.botsvsbrowsers.com/category/1/index.html
> 
> Unfortunately this is incompatible with the data format used by
> robotstxt.org/robot-detection:
> 
> http://www.robotstxt.org/db/all.txt
> 
> So you can see from the botsvsbrowsers.com data, the User-Agent field
> is often bogus or contains vulnerability attack patterns and is thus
> mostly not useful at all and should probably just be ignored by all
> web apps at this point.
> 
> So I would suggest convincing upstream to remove whatever use of
> robot-detection is present in mailman3 or hyperkitty.

That's in progress, the only goal of this detection is to deactivate
javascript dynamic load of threads. We're thinking about alternative
solutions.

> > That leaves me with django-gravatar2, that seems useful, and is still
> > developed. I heard there is some kind of "canonical" way of packaging django
> > apps. As I'm not used to that, I'm here to ask advice.
> 
> I would suggest upstream switch from Gravatar (a centralised
> proprietary service) to Libravatar (a federated Free Software service
> that falls back on Gravatar):
> 
> https://www.libravatar.org/

I understand your point, and I'll think about it, but my goal is to make
upstream remove obsolete dependencies. django-libravatar seems to be the
only project that bundles support for that, and it's not maintained, whereas
django-gravatar2 is still maintained.

So, for now, I think that I'd rather have a first mailman3 suite in debian,
and then, think about how to make things better. :)

> Re canonical django packaging, you may be talking about this:
> 
> https://wiki.debian.org/DjangoPackagingDraft
> 
> There are also lots of python-django-* packages in Debian that you
> could look at.

Thanks!

-- 
PEB

Re: Packaging pythonpy

[Tiago Ilieve]

Hi Gianfranco,

On 25 March 2016 at 06:25, Gianfranco Costamagna
 wrote:
>
> adding python to the dependencies?
> do you have python to build dependencies, dh-python and python:Depends on the
> binary package?

This is what is strange. I've made the following changes:

-
diff --git a/debian/control b/debian/control
index f0c1b3f..5205298 100644
--- a/debian/control
+++ b/debian/control
@@ -3,6 +3,7 @@ Section: python
 Priority: optional
 Maintainer: Tiago Ilieve 
 Build-Depends: debhelper (>= 9),
+   dh-python,
python (>= 2.7.3),
python-setuptools (>= 0.6.24)
 Standards-Version: 3.9.7
@@ -13,7 +14,9 @@ Vcs-Browser: https://github.com/myhro/deb-pythonpy

 Package: pythonpy
 Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
+Depends: python (>= 2.7.3),
+ ${misc:Depends},
+ ${python:Depends}
 Description: 'python -c', with tab completion and shorthand
  pythonpy is an utility that facilitates the usage of Python one-liners. The
  command 'py' evaluates a string consisting of any Python expression. It can do
-

But this didn't helped at all. The lintian.d.o page for
"python-script-but-no-python-dep"[1] says:

"Packages with Python scripts should depend on the package python.
Those with scripts that specify a specific version of Python must
depend on that version of Python (exactly).

For example, if a script in the package uses #!/usr/bin/python, the
package needs a dependency on python. If a script uses
#!/usr/bin/python2.6, the package needs a dependency on python2.6. A
dependency on python (>= 2.6) is not correct, since later versions of
Python may not provide the /usr/bin/python2.6 binary."

What is the "exactly" version of Python for a script which has
"#!/usr/bin/env python2" as its shebang?

> it is generated *during/after* the build, so the clean target won't work.
>
> a "package.pyremove" file might help, not sure
>
> codesearch.debian.net might help
> egg path:pyremove$
>
> https://codesearch.debian.net/results/egg%20path%3Apyremove%24/page_0

"pyremove" didn't worked, but in the same page that I found references
to it[2], there's a suggestion to override "dh_python", which is what
I did[3]. Thanks for the suggestion. :-)

Regards,
Tiago.

[1]: https://lintian.debian.org/tags/python-script-but-no-python-dep.html
[2]: 
https://wiki.debian.org/Python/LibraryStyleGuide#Python_3.3.2F3.4_unittest_fixers_for_2to3
[3]: https://github.com/myhro/deb-pythonpy/commit/68db18e

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Packaging dependencies for mailman3-hyperkitty

[Barry Warsaw]

On Mar 25, 2016, at 01:02 PM, Paul Wise wrote:

>Does HyperKitty depend on mailman3 or just enhance it by providing an
>archive web interface?

Although greatly enhanced by it, Mailman 3 (core) doesn't require HyperKitty.
HK isn't currently useful on its own though.

Cheers,
-Barry


pgp3ExyuUZIGA.pgp
Description: OpenPGP digital signature

Re: running tests against installed version of package

[Ben Finney]

Brian May  writes:

> Vcs-Git: git://anonscm.debian.org/python-modules/packages/apscheduler.git
> Vcs-Browser: 
> https://anonscm.debian.org/cgit/python-modules/packages/apscheduler.git

The “git:” URL method is not encrypted. You should specify the encrypted
“https:” method in the “VCS-Git” field:

Vcs-Git: 
https://anonscm.debian.org/git/python-modules/packages/apscheduler.git

-- 
 \  “That's all very good in practice, but how does it work in |
  `\ *theory*?” —anonymous |
_o__)  |
Ben Finney

Re: Packaging pythonpy

[Gianfranco Costamagna]

Hi Tiago,



>* How to fix the "python-script-but-no-python-dep" lintian error? I've
>tried with and without pybuild and the error still persists.


adding python to the dependencies?
do you have python to build dependencies, dh-python and python:Depends on the 

binary package?


>* How to get rid of the ".egg-info/" folder that is being packaged?>Looks like 
>"debian/clean" rules aren't working.


it is generated *during/after* the build, so the clean target won't work.

a "package.pyremove" file might help, not sure

codesearch.debian.net might help
egg path:pyremove$

https://codesearch.debian.net/results/egg%20path%3Apyremove%24/page_0


cheers,

G.

There's a GitHub repository for the package[1]. I have intention on
asking for a repository on collab-maint when the package is ready (I
have write permissions to it).

Regards,
Tiago.

[1]: https://github.com/myhro/deb-pythonpy


-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

running tests against installed version of package

[Brian May]

Hello,

By default pybuild runs tests I think using the source tree.

However I have a package where the tests require the entry points from
setup.py to be configured, the tests fail without this.

So what is the appropriate way to modify debian/rules to get the tests
to run from the installed version with the entry points available?

This is:

Vcs-Git: git://anonscm.debian.org/python-modules/packages/apscheduler.git
Vcs-Browser: 
https://anonscm.debian.org/cgit/python-modules/packages/apscheduler.git

(I considered moving this to become DPMTs maintained, however it appears
the original package maintainer is still interested; so the above
repository may not stay)

See #807797

I filled an uptream bug report before I realized what the problem is:

https://bitbucket.org/agronholm/apscheduler/issues/114/lookuperror-no-trigger-by-the-name-date

Thanks
-- 
Brian May 
https://linuxpenguins.xyz/brian/