Re: GUI tool for packaging
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
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
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
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
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
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
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
