[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#825112: (no subject)



On 07/06/16 18:22, Barry Warsaw wrote:
> On Jun 07, 2016, at 10:35 AM, Gordon Ball wrote:
> 
>> Packaging has been done and can be found in collab-maint [1]
>> (git-buildpackage+pristine-tar format [2]). Current version is
>> 0.3.3+dfsg. Builds for xenial/yakkety can be found in a PPA [3].
> 
> Cool.  I grabbed and looked at the collab branch.
> 
>> The packaging and test suite appear to work, but I've held off trying to
>> get it uploaded since there have been several minor versions in quick
>> succession recently (0.3.0 .. 0.3.3 in the last two weeks) and I was
>> waiting to see if it would settle.
> 
> Hopefully that will calm down after the rush of Pycon.
> 
>> Would you be willing to review and possibly sponsor?
> 
> For sure.  Would you consider adding me to Uploaders?

Done.

> 
> The packaging looks really good.  I noticed the setting of http_proxy in
> override_dh_auto_build.  You probably don't strictly need that because I
> believe pybuild does that automatically.  It can't hurt though and some
> maintainers prefer to be explicit about that.

The http_proxy bit was cargo-culted from
https://wiki.debian.org/Python/LibraryStyleGuide

> 
> It might be good to add an autopkgtest that actually runs the installed xonsh
> as a sanity check.  Maybe even just run a simple xonsh script?  See below.

Good idea. The test suite is extensive but it hadn't occurred to me that
it is entirely based on importing it as a library rather than actually
running the binary. I'd tested the installed package but clearly on a
system with python3-pkg-resources already installed.

I found that this fails in an autopkgtest schroot though - xonsh fails
to start if $HOME is not writable (which is possibly a bug), so I've
added a wrapper which sets $HOME=$ADTTMP (and added a couple of extra
examples).

> 
> Should debian/xonsh.1 be generated from help2man so it doesn't get out of
> sync?

I've implemented this (help2man plus some added sections).

> 
>> [2]: This should probably be under DPMT and git-dpm, but I'm not (yet) a
>> team member
> 
> You should definitely join debian-python!  However, as this is an application
> and not a library, it would probably be best to put it under PAPT.  The
> problem there of course is that PAPT hasn't switched to git yet :(.  I'm
> hoping tumbleweed and others might make that happen at or after debconf2016.
> Until that happens, collab-maint is fine.

On hold for the moment then. I'm happy to have it listed as team
maintained at a future point though. I'm already subscribed to
debian-python, I'll apply to join the relevant teams soon.

> 
>> [3]: ppa:chronitis/misc (contains a variety of other stuff)
> 
> Cool!
> 
> /me builds
> 
> Love the logo output during `python3.5 setup.py clean` ;)
> 
> I think you need to explicitly depend on python3-pkg-resources, otherwise:

Given the script is generated based on `entry_points` in setup.py,
shouldn't this dependency be generated by pybuild/dh_python?
> 
> # xonsh
> Traceback (most recent call last):
>   File "/usr/bin/xonsh", line 5, in <module>
>     from pkg_resources import load_entry_point
> ImportError: No module named 'pkg_resources'
> 
> I made a few of the suggested changes (adding the Depends and an autopkgtest)
> and pushed it to the `review` branch on collab-maint.  Let me know what you
> think.  Great work, and I'm happy to sponsor and/or comaintain xonsh!
> 

Merged (and further modified as noted above).

There are a couple of remaining (possibly non-) issues:

 * lintian reports privacy-breach-generic on the documentation (google
webfont links). I can't see this explicitly configured anywhere in the
rst files or conf.py, so I *think* this is being added by
sphinx/cloud-sptheme
 * building the documentation generates (I think) inconsequential errors
since the xonsh pygments lexer is not available at build time; this
could be fixed by build-depending on itself, but I'm not sure this is
worth adding a dependency cycle for.
 * xonsh supports installing itself as a jupyter kernel, which I'm
interested to include but for the moment (parts of) jupyter is only in
experimental, so it can probably wait until a future xonsh upload


Reply to: