Re: GUI tool for packaging

2012-11-15 Thread Barry Warsaw
On Nov 15, 2012, at 04:15 PM, Thomas Kluyver wrote:

>- uscan puts upstream tarballs into ../, but svn-buildpackage expects them
>in ../tarballs/

>- To work on patches, you have the debian/ directory in amongst the
>upstream codebase. But having the rest of the codebase there clutters up
>information from the version control system. So I often end up with two
>copies of the packaging, and copying debian/patches/ between them.

Ubuntu Distributed Development (UDD) fixes both these real problems.  Ignore
the choice of dvcs for the moment, the fact that you can branch a source
package that gives you upstream + debian, with quilt applied, is a huge win.
Once you've branched, you just start hacking.  Then bzr-builddeb does all the
magic of creating the source and/or binary packages.  No mucking about with
orig.tar.gz locations, uscan, mergeWithUpstream, etc, etc.

IMHO, UDD makes developing for Ubuntu much easier and faster than developing
for Debian, and a downright joy (usually, at least these days :).

In fact, Launchpad imports Debian source packages too, so even using UDD for
Debian development (modulo updating the svn branches) much easier too.

I think it would be very cool if Debian were to adopt the UDD workflow.  I
know there are problems, controversies, and detractors, but I find it so much
more pleasant to develop with.

>- In the .install list, a line with a single entry works quite
>differently from a line with two entries

Yes, and the documentation about this isn't great.

>- When you make a new patch, you have to 'quilt add' any files you want to
>modify before you can modify them. It's easy, and annoying, to forget that.
>(I know about 'quilt edit', but for other reasons my $EDITOR is set to an
>in-terminal editor, which isn't what I prefer for modifying large code
>files)

Agreed.  The larger problem is that if you forget to quilt add before you edit
the file, adding it after the fact doesn't help.  So you better have those
files under vcs so you can undo your change, quilt add the file, and then redo
the change.  This is another way that UDD helps quite a bit.

>- You call pbuilder with a .dsc file, but dput with a .changes file.

Yeah, that one annoys me too. ;)

>To be clear, I'm not asking for solutions or workarounds to these
>individual issues. I'm sure there are good reasons things work the way they
>do - but being relatively new to this, the array of not-quite-connected
>tools is daunting.

You've identified real problems that don't really go away, you just learn
crufty workarounds and ignore the pain.  OTOH, none of these are really
solvable by what *I* think of when I hear "graphical packaging tools".  Maybe
I'm just thinking about it too narrowly.  I'm also not much of a GUI person,
so I do like the command-line-iness of the UDD workflow.  But maybe I'd fire
up the GUI once in a while to inspect a package I'm not familiar with.

Cheers,
-Barry


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121115151205.2b662...@resist.wooz.org



Re: GUI tool for packaging

2012-11-15 Thread Thomas Kluyver
On 15 November 2012 15:18, Andrey Rahmatullin  wrote:

> Bottom line: if you want to get a good package, it's not always possible
> to fully automate that, especially in cases of complex (and proprietary)
> software like that you mentioned, and so a GUI wizard can't do everything
> needed.
>

I absolutely agree, but as I see it, I'm not trying to automate the
process. I'm trying to make it easier for the user to manually intervene in
the packaging. The wizards are just one part of that.

Packaging at the moment involves an array of different data files,
specialist syntax, and command line tools. There's a lot of detail which is
hard to learn and remember. For example:
- uscan puts upstream tarballs into ../, but svn-buildpackage expects them
in ../tarballs/
- dh_make is something for the user to run, whereas dh_install is something
to be run automatically by the build system.
- When you make a new patch, you have to 'quilt add' any files you want to
modify before you can modify them. It's easy, and annoying, to forget that.
(I know about 'quilt edit', but for other reasons my $EDITOR is set to an
in-terminal editor, which isn't what I prefer for modifying large code
files)
- To work on patches, you have the debian/ directory in amongst the
upstream codebase. But having the rest of the codebase there clutters up
information from the version control system. So I often end up with two
copies of the packaging, and copying debian/patches/ between them.
- You call pbuilder with a .dsc file, but dput with a .changes file.
- In the .install list, a line with a single entry works quite
differently from a line with two entries

To be clear, I'm not asking for solutions or workarounds to these
individual issues. I'm sure there are good reasons things work the way they
do - but being relatively new to this, the array of not-quite-connected
tools is daunting.

I think the advantage of a GUI is that it presents your options, rather
than requiring you to already know them. If you realise you need to change
some of upstream's code to make the package work... hey, that pane says
'patches', that sounds like the thing. If there are some examples, you can
see the binary package target has an entry called 'examples'.

Specifically, some of the things I have in mind:
- Integration with quilt for patches. If you try to edit a source file from
the GUI, you're prompted to create a patch.
- A joined-up view of the intended binary packages. At present, the details
of a binary package are spread out over part of the control file, and the
foo.install, .docs, .examples, etc. files.
- Editing copyright info without having to get the file syntax just right,
look up license short names, and so on. Just enter a glob and select the
license from a dropdown.
- Wizards for specific things like watch files or DEP-8 tests. The key to
this is that GUI wizards have a much lower barrier of entry than new
command line tools - no flags to remember.
- A build menu where you can select source package, local build, pbuilder
or PPA, and it will take care of any preparation needed for that.

Whew, that's more than I meant to write. Thanks to anyone who's read this
far - I hope I've managed to give a clearer picture of what my idea
involves.

Thanks,
Thomas


Bug#693335: RFS: pymarkups/0.2.3-1

2012-11-15 Thread Dmitry Shachnev
Package: sponsorship-requests
Severity: wishlist

Dear mentors/pythoneers,

I am looking for a sponsor for my package "pymarkups". It is based on code
that has been split out of ReText so that it could be used by other apps
(including ReText export extensions).

It is a dependency of ReText 4.0, which will be released soon.

Only the Python 3 version is provided since ReText will be using Python 3 by
default (and I don't know any apps that are going to use the Python 2
version).

 * Package name: pymarkups
   Version : 0.2.3-1
   Upstream Author : myself (Dmitry Shachnev)
 * URL : https://launchpad.net/python-markups
 * License : BSD
   Section : python

It builds this binary package:

  python3-markups - Wrapper around various text markups, implemented in Python 3

To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/pymarkups

Alternatively, one can download the package with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/main/p/pymarkups/pymarkups_0.2.3-1.dsc

More information about hello can be obtained from 
https://launchpad.net/python-markups.

The package is also in DMPT SVN:

  svn://svn.debian.org/svn/python-modules/packages/pymarkups

It would be very good if you sponsored it for me.

Thanks in advance,

--
Dmitry Shachnev


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121115155257.5651.80961.reportbug@eeepc



Re: GUI tool for packaging

2012-11-15 Thread Andrey Rahmatullin
On Thu, Nov 15, 2012 at 11:17:40AM +, Thomas Kluyver wrote:
> I have been keeping an eye on pkgme, but I'm not sure it solves the
> problem. My concern with automated tools is that they tend to to work for
> about 75% of stuff, but there's always a substantial proportion of things
> that just do something a little bit odd, and the automatic tool can't
> handle them.
Of course. That's still applicable to your collection of GUI wizards.

> But neither can handle enough real-world cases that new packagers can
> use it without thinking about what's happening.
"Packaging without thinking about what's happening" is bad.
It's good to have tools that do the right thing without you intervening
(like debhelper). It's good to have tools that generate some
configs/instructions based on analysis of sources and/or user input
(needed when the first kind of tools doesn't work). In most cases
packaging can be done with a combination of those and probably some small
manual work, but I don't see how some big non-flexible GUI app can help
users get a working package without doing manual checks and fixes.

Bottom line: if you want to get a good package, it's not always possible
to fully automate that, especially in cases of complex (and proprietary)
software like that you mentioned, and so a GUI wizard can't do everything
needed.

-- 
WBR, wRAR


signature.asc
Description: Digital signature


Re: GUI tool for packaging

2012-11-15 Thread Thomas Kluyver
Hi Clint,

On 15 November 2012 03:53, Clint Byrum  wrote:

> https://launchpad.net/pkgme
>
> At one point I was interested in writing a ruby backend for this, but
> got distracted and moved to other focus, but I think it solves what you
> are talking about, without need to develop a large project like a GUI.


I have been keeping an eye on pkgme, but I'm not sure it solves the
problem. My concern with automated tools is that they tend to to work for
about 75% of stuff, but there's always a substantial proportion of things
that just do something a little bit odd, and the automatic tool can't
handle them. So I have to understand what the automation is doing, to deal
with the things it can't do for me.

To give more concrete examples, we have stdeb for Python packages, and
debhelper, which can guess much of the standard process of building a
package (such as running 'make' or 'setup.py'). But neither can handle
enough real-world cases that new packagers can use it without thinking
about what's happening.

I tried writing an application with Quickly a couple of months ago, and I
was impressed with how well 'quickly package' (which uses pkgme) worked.
But a lot of things that I'd like to see packaged aren't developed with
Quickly, and I'm not confident that pkgme can do such a good job with them.

Thanks,
Thomas


Re: Revisiting team joining procedures

2012-11-15 Thread Andreas Tille
On Wed, Nov 14, 2012 at 08:04:11PM +0100, Jakub Wilk wrote:
> I'm afraid that this creates false impression that we'd accept
> anyone, without any questions asked. This is not the case. As a DPMT
> admin I required that the applicant:
> 1) either had existing Python-related packages in the archive;
> 2) or shown me his existing Python-related packaging work (e.g. by
> uploading stuff to mentors.d.n);
> 3) or was a DD;
> 4) or was advocated by a DD team member.
> ...

As far as I understand your question it is about lowering or heightening
the entering barrier.  I'm a friend of low barriers for newcomers and I
explicitely invite newcomers and try to train them (see for instance
MoM[1].)  The only sanity check I try to approach is that I ask people
for their reasons to join to make sure that we do not add anybody to the
project in question who did not really understand the goals and just has
a good feeling by beeing a member of just another project.  I'm also
considering cleaning up the list of people who never did a single commit
for years (I just did not yet because it simply costs time to do this.)

The only reason for heightening the barrier in my opinion would be that
you realise that to much of the team members time is drained to welcome
and teach newcomers (yes, MoM etc. costs time.)  I have no idea whether
you are in this situation.

Kind regards

   Andreas.


[1] https://wiki.debian.org/DebianMed/MoM

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121115081238.gb5...@an3as.eu



Re: Second round of advise on packaging python-csb

2012-11-15 Thread Andreas Tille
Hi Tomás,

On Wed, Nov 14, 2012 at 04:42:19PM +0100, Tomás Di Domenico wrote:
> > 
> > Ideally, the documentation should be rebuilt from source.
> 
> Right, things get a bit blurry for me here. When upstream releases a new
> version, they take a snapshot from their repository and build the
> release tarball. This process includes the creation of the docs from
> source. The tarball I use for the package, therefore, has the already
> cooked HTML files, and I happily committed them to the repository.

If Jakub wrote *ideally* than he most probably intended to write that we
should try to do so but there might be some good reasons to derive from
this ideal situation.  I admit, I usually try to rebuild the docs in my
packages and I do at least verify that I can *reproduce* all the docs.
However, sometimes there are good reasons to simply use the
autogenerated docs from upstream.  Without having checked the thing
myself your description sounds as if it could be the case here.

> Seeing as it's 24M of HTML files, it would most likely be a different
> package. However, I assume from your comment about rebuilding from
> source that it would not be as easy as taking the "docs" dir and
> packaging it separately?

IMHO the question whether you rebuild the docs from source and the fact
whether the docs will end up in a separate binary package are
orthogonal.  I'm a fan if separate docs and I think 24MB are some good
reason to do this.

> Another blurry point. I'm having a hard time understanding the
> separation of tasks between the tarball packaging done by upstream I
> described before, and my Debian packaging. Similar to the docs, the
> tests are run by upstream when they build the tarball. Is it common to
> also include these tests in Debian packages?

I agree with those other to people who answered this part of your mail
that having the tests packaged and thus ready for testing by the user
at the installation target (which is simply different from testing at
upstream side) is a very good idea and should be approached.  Please
also regard Jakub's (?) hint to DEP8.

Kind regards

  Andreas. 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121115080131.ga5...@an3as.eu