Re: using git-dpm or plain git-buildpackage in PAPT and DPMT
Raphael Hertzog writes: > Anyway, +1 from me to switch to git-buildpackage and in fact among the > python-django maintainers we are close to decide to switch back to > git-buildpackage because it's really horrible to use when you want to > merge across branches of different releases. Have people here seen the following thread on debian-devel? Subject: "[ANNOUNCE] git-series: track changes to a patch series over time" Might be worth looking at this thread, even if the conclusion is that this is not a good solution (actually I don't really understand it and haven't time to understand it). -- Brian May
Re: using git-dpm or plain git-buildpackage in PAPT and DPMT
On Wednesday, August 10 2016, Nikolaus Rath wrote: > I don't believe that switching from git-dpm to git-buildpackage is going > to make things easier, it'll just be trading one set of problems for > another. I understand this is a matter of personal taste, but I beg to differ. I have been using git-buildpackage for most of my non-Python packages and, despite really small nits here and there, I think it is an awesome tool. git-dpm, OTOH, has several limitations (as already mentioned by others, it's not trivial to merge changes to local patches, and it can be quite complicated to import a new upstream version into the repository). I have had to package some Python packages these last weeks, and every time I had to deal with git-dpm I almost always stumbled upon some idiosyncrasy that got in the way of my work. Long story short: I am totally favorable to make the switch to git-buildpackage (in fact, I recently raised this topic on IRC but the conversation eventually died). Cheers, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Re: using git-dpm or plain git-buildpackage in PAPT and DPMT
On Aug 12, 2016, at 05:50 PM, Sergio Durigan Junior wrote: >I understand this is a matter of personal taste, but I beg to differ. I >have been using git-buildpackage for most of my non-Python packages and, >despite really small nits here and there, I think it is an awesome tool. I think there are multiple ways in which git-buildpackage is used. E.g. I use `gbp buildpackage` even for git-dpm maintained packages, to build the source package, etc. (It even has a nicer `clone` command that makes it easy to actually get tracking branches; just wish it had something like `pull-and-update-all-branches` since it's a bit of a PITA to update the pristine-tar branch.) It's just the few things that git-dpm adds on top of gbp that we're discussing getting rid of, like importing a new upstream, managing the quilt patch set, tagging. Cheers, -Barry pgp7ppU1EAjvh.pgp Description: OpenPGP digital signature
Help for Python mock test suite needed (Was: Any help with problem of srst2 new versions tests suite failing to call bowtie2)
Hi, I've got no help on the Debian Med packaging list. Is there any hint how I could track down a test Python suite issue what exact command was called and failed? Thanks for any hint Andreas. On Tue, Aug 09, 2016 at 11:32:40PM +0200, Andreas Tille wrote: > Hi, > > I tried to update srst2[1] package to new upstream version. > Unfortunately its runtime test produces failures when calling bowtie2. > I just added some naive debugging code writing the actual system call > to a file - but this has not lead to a final solution even if I think > the invalid option -foo was wrong. > > Any more complete hint from a possibly bowtie2 user would be helpful > > Andreas. > > > [1] svn://anonscm.debian.org/debian-med/trunk/packages/srst2/trunk/ > > -- > http://fam-tille.de > > ___ > Debian-med-packaging mailing list > debian-med-packag...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging > -- http://fam-tille.de
