Re: Bug#758013: s3ql autopkg test regression

[Nikolaus Rath]

Simon McVittie  writes:
> On 19/08/14 09:33, Matthias Klose wrote:
> [Nikolaus Rath wrote:]
>>> That's a bug in the test (race condition) rather than in the program.
>>> It's fixed upstream.
>> 
>> [...] If you don't care
>> about the autopkg tests, and if you are not ready to fix these but rather 
>> wait
>> for the fixes from upstream (and maybe new bugs), then I think it's better to
>> drop the autopkg tests.
>
> There are always at least two possible reasons for a failing test: "the
> code under test is wrong" or "the test is wrong".
>
> The most important thing is that someone with knowledge of the package
> has looked at the failure report and triaged it, i.e. assigned it an
> appropriate priority based on their knowledge of the package. It appears
> Nikolaus has done this, and it will be dealt with when it's dealt with.
> I don't think there's a problem here.

If someone cares deeply about this, the necessary patch is at 
https://bitbucket.org/nikratio/s3ql/commits/9a8c0ebbff390555e63b7e203b999b89aabbb86e/raw/.
 

I did not add it to the debian package yet because I considered it a
minor issue that I did not want to bug my sponsor with. But if some DD
wants to sponsor a new upload right away to get this fixed, I'm happy to
update the package in SVN. Otherwise I'll wait for a new upstream
version.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87mwazahl6@vostro.rath.org

Re: Bug#758013: s3ql autopkg test regression

[Nikolaus Rath]

On 08/19/2014 01:33 AM, Matthias Klose wrote:
> Control: severity -1 important

Care to provide a justification? There is no bug in the program itself,
so I don't see how this is has a "major effect on the usability of a
package".

>> That's a bug in the test (race condition) rather than in the program.
>> It's fixed upstream.
> 
> Nikolaus, I find this kind of attitude rather disturbing.  If you don't care
> about the autopkg tests, and if you are not ready to fix these but rather wait
> for the fixes from upstream (and maybe new bugs), then I think it's better to
> drop the autopkg tests.

What makes you think I'm not ready to fix them?

And even if was my intention to wait for a new upstream version instead,
I think I'm a bit more qualified than you to judge if that's a good idea
or not.

> And replying to the bug report without replying to the maintainer is at least 
> odd.

What do you mean? I am the maintainer.

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f4154c.1010...@rath.org

Playing with git-dpm

[Barry Warsaw]

lazr.smtptest wasn't packaged in Debian yet, so I thought it would be a good
candidate for experimenting with one of the git-based workflows, from scratch.
The ITP is bug #758670.  I decided to use git-dpm; here are my impressions so
far.

For reference I started with https://wiki.debian.org/PackagingWithGit/GitDpm
but ended up using the git-dpm(1) manpage more than the wiki page.  I think
it's helpful to read through both, but I noticed some slightly different
recommendations, especially when creating the initial repository.  I think the
manpage recommends creating the pristine-tar branch but the wiki omits that
step.  I have no opinion on whether it's good or bad, but I followed the
manpage and created the pristine-tar branch.

I needed to create the initial packaging, and I needed to patch upstream[1].

The workflows described in the manpage seemed easy enough to follow.  As
described in the d/README.source file, I ended up using upstream-lazr.smtptest
as the upstream branch, added a pristine-tar branch, and used lazr.smtptest as
the packaging branch (i.e. the one with the debian/ directory).  When just
mucking about in debian/ I was pretty much able to use normal git commands,
and to build the package I just used `debuild -S` without trouble[2].

It was easy to tag the release using `git-dpm tag` and even to move the tag
once with --refresh.  All in all, it was a pleasant experience, but there were
a few hiccups, as described following.

* The egg-info directory is a PITA.

The upstream tarball has a lazr.smtptest.egg-info directory.  debuild -S blows
this away, and then git thinks I want to delete it.  It doesn't get staged, so
it's easy to `git checkout -- lazr.smtptest.egg-info`[3], but it gets annoying
*very* quickly after just a few debuilds.  I'm not sure what the best way to
handle this is, if there is one.

* debian/patches/* get named automatically

`git-dpm checkout-patched` creates a temporary patch branch.  I had to patch
the setup.py, so I just edited it as normal.  Note though that you *must*
commit this file while on the patch branch or it doesn't get quilt-ified, but
it will still show up as modified on your packaging branch if you switch to
it.  Oh, and the first line of your commit message gets turned into patch
name.  I like that it handles quilt-ifying the patch automatically when you
`git-dpm update-patches` but watch out with your commit messages or you may be
left with a patch file that has an odd name.  I didn't try to change that and
see if git-dpm could still grok the patch.

* You have to switch branches to build the package.

I'm used to svn-bp's --svn-ignore-new feature where you can just make the
change and build the package right there.  This doesn't work in git-dpm
because the temporary patched-lazr.smtptest branch does not contain a debian/
directory.  This makes the workflow for developing a patch less convenient
because you have to switch back and forth between branches in order to build
and test your patch.

* Switching branches makes my editor unhappy.

Why is this a PITA?  Because Emacs will notice that a file you're visiting in
a buffer is changed and will prompt you reload it.  I guess because
checkout-patched deletes the debian directory and update-patches restores it,
it makes Emacs unhappy.  I suppose you also have to be careful not to write a
buffer to the debian/ directory when in the patched- branch.

* Where to push the repo?

I'm not sure that we have a definitive path on git.debian.org for team
maintained packages under git, but there is a python-modules directory
containing a few packages.  So I pushed my branches to
git+ssh://git.debian.org/git/python-modules/packages/lazr.smtptest.git

It takes a bit of work to create this directory initially, but I found that
gbp has a nice command you can corrupt  into doing the right thing for
you, e.g.:

$ gbp create-remote-repo --remote-url-pattern 
"ssh://git.debian.org/git/python-modules/packages/%(pkg)s.git" --debian-branch 
lazr.smtptest

The --remote-url-pattern option is needed to override the default collab-maint
directory.  The --debian-branch options is required for some reason.  I'm not
sure why it needs a branch here since it creates an empty repository, but it
failed without it.  After running this command, I set up a remote and pushed
all three branches (the upstream, pristine-tar, and packaging branches), along
with the tags, and everything seemed happy.

Oddly, I don't see the repo here: http://anonscm.debian.org/cgit/ but I have
no idea why.

If this isn't a good location, let's decide on one and use it consistently.
I'd rather it be something team oriented, not collab-maint.  My choice seemed
good enough for the Vcs-* headers for now, but I'm happy to move it to a
better place if there is one.

Anyway, I think that's it for now.  Feel free to muck about in this package,
but please do let me know if you want to push any permanent changes.  Tomorrow
I'll probably try to do a new upstream release to

Re: Two django packages for Debian?

[Barry Warsaw]

On Aug 19, 2014, at 11:14 AM, Barry Warsaw wrote:

>I usually don't care much about preserving local intra-upload vcs history

Ah, except for the case where I want to collaborate with someone on the new
version, e.g. to get a code review of some packaging change *before* it gets
uploaded.  This is especially true for team members who don't have upload
rights.  I think it would be great if they could push their proposed packaging
changes, which I could fetch, review, edit, push, merge, and upload.  It would
be nice to be able to capture a conversation between developers, e.g. as in a
github pull request[*].

-Barry

[*] No, I don't suggest using github; it's not free software.


signature.asc
Description: PGP signature

Re: Two django packages for Debian?

[Sandro Tosi]

> If it were well integrated with quilt, I think it would be fine to have
> source-full branches.  I like this aspect of UDD, but I've also become
> comfortable working with our svn debian-only branches.  It usually means
> unpacking the tarball, cd'ing into that directory and symlinking in debian/ to
> work with the patch stack.

you might want to try svn-do

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cab4xwxw8rx20ad42wjtnvjeojrdqc44chpsqrduroj+j5wc...@mail.gmail.com

Re: Two django packages for Debian?

[Barry Warsaw]

On Aug 09, 2014, at 06:02 PM, Brian May wrote:

>At the moment, in subversion, we only store the debian/* directory. Is
>there any requirement/benefit in putting the full upstream source in git
>too?

If it were well integrated with quilt, I think it would be fine to have
source-full branches.  I like this aspect of UDD, but I've also become
comfortable working with our svn debian-only branches.  It usually means
unpacking the tarball, cd'ing into that directory and symlinking in debian/ to
work with the patch stack.

It's a bit jarring though, since I have to go back to the svn branch directory
to build the packages (source or binary), so I'm always flipping between the
two directories.

The other thing that *has* to work flawlessly for source-full checkouts is
importing new upstream versions.  If you do this naively in a UDD branch,
you're screwed.  `bzr merge-upstream` is the trick to make this work, since it
updates the upstream source to match the tarball.  I think this step should
re-apply the quilt stack automatically, but of course scream loudly if it gets
to a patch that is out of date.

I guess I can summarize this as comfort != joy.  :)

-Barry


signature.asc
Description: PGP signature

Re: Two django packages for Debian?

[Barry Warsaw]

On Aug 06, 2014, at 04:08 PM, Piotr Ożarowski wrote:

>and I would love to try them all before we make a decision¹

Me too.

Should we relax the team preference for one vcs to rule them all, at least for
a period of experimentation and experience sharing?   I still *really* want to
end up in a place where team packages use one vcs and one common workflow, but
it may be time to allow for some non-svn managed packages.

If we did, I would pick one or two of the ones I touch and experiment with
some of the git packaging tools.

(I suspect this may be a big topic for us at DC14 :).

-Barry


signature.asc
Description: PGP signature

Re: Two django packages for Debian?

[Barry Warsaw]

On Aug 06, 2014, at 02:28 PM, Dimitri John Ledkov wrote:

>I am on the edge. I prefer dgit, as it's the only one the guarantees
>round-trip save with the archive even when someone NMUs things without using
>dgit.

From this description, it sounds like dgit is the closest equivalent to Ubuntu
Distributed Development (UDD) branches, which of course I am a big fan of[*].
Even with today's svn-based workflow, it bothers me that a packaging branch
and the archive might not agree about the state of a package.  I've seen this
a few times IRL, and it's always a mess to unwind because usually one is not a
superset of the other.  It's no fun to merge.

>However, it does not integrate with git-dpm at the moment and there is
>no clear conversion / vcs history import available. Do we care about
>preserving vcs history for our packages? Do we want synthetic history
>(e.g. per upload granularity)?

I usually don't care much about preserving local intra-upload vcs history, and
think that it's fine to have per-upload granularity in the public package
repo.  Yes, I'll use lots of intermediate commits locally until I'm happy that
the next version of the package is ready to upload, but those can be safely
rebased away on upload.

(Ironically, this is opposite of my preferences when doing upstream
development.  In those cases, I want the intermediate commits to be preserved,
but in a bzr-style mainline approach, where they're generally hidden to log
and bisect commands.  In git parlance I think that's --first-parent by
default, which doesn't seem to be what git fans use or expect.)

We've had debates in UDD circles about whether it's okay to push UDD branches
or let the package importer do that step.  I personally prefer the latter
because it's safer - i.e. if the importer updates the branch on package
upload, then there's less chance that the UDD branch breaks.  But that's a
superstition.  From reading the manpage, it sounds like `dgit push` is ideal -
it does the upload and pushes the branch so that collaborators would have
immediate access to the new version without the need for an importer run.

I just tried `dgit clone tox` since that's a package I intend on working on
today.  It's nice that I got a quilt-pushed source checkout; it means I can
start hacking right away.  I was dismayed though that there doesn't seem to be
any upload history.  There's only one commit and it's the last upload.  There
are no tags.  I want the upload history to be reflected in the commit log and
tags.  Is there a way to synthesize the entire upload history with dgit?

Also, reading the dgit manpage it seems like `3.0 (quilt)` integration isn't
entirely smooth.  I like working with quilt, but would also like better vcs
integration.  In my limited experience git-dpm seemed the nicest here.

Cheers,
-Barry

[*] In the parallel universe where import failures never occur, bzr is
blindingly fast, and bzr won the war. ;)


signature.asc
Description: PGP signature

Re: Bug#755757: transition: wxpython3.0

[Dmitry Shachnev]

On Mon, Aug 18, 2014 at 2:58 PM, Olly Betts  wrote:
> On Wed, Jul 23, 2014 at 03:33:03PM +0200, Matthias Klose wrote:
>> Asking what will happen with packages depending on wxPython 2.8 and
>> which cannot be converted to 3.0.
>
> There aren't many incompatible changes between wxPython 2.8 and 3.0.
> With the C++ API, the Unicode changes have been quite painful, but
> that's simply not relevant to wxPython.
>
> My hope is that we will get all packages converted, though I know from
> the wxwidgets2.8 transition that there are a few rdeps which are dead
> upstream and effectively unmaintained in Debian.  If such a package
> isn't actually working currently and nobody has reported it, removal
> might be the best option.

Hi Olly, and thanks for working on wxpython3.0 transition.

While this is not directly related to the transition, can you please
use the correct package naming for python packages (at least in
future)?

For example, you recently (~ 2 days ago) added a new binary package:

* New binary package python-gtk-media3.0 for wx.media.  (Closes: #722687)

Per the Python policy [1], it should have been named python-wx.media,
not python-gtk-media3.0 (we have these naming rules so that it's
easier to guess which package a module is in).

[1] 
https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names

--
Dmitry Shachnev


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKimPHUCMX=jLxo_yJSDpE5kwCpsALyuk8ZrnG=gt1urzpo...@mail.gmail.com

Re: librabbitmq and git

[Barry Warsaw]

On Aug 18, 2014, at 09:22 PM, Tianon Gravi wrote:

>On 18 August 2014 18:11, Brian May  wrote:
>> Unfortunately, debian/watch (AFAIK) doesn't include any details of any
>> changes that were made to the tar.gz file by the package developer.
>
>It's been my understanding that this is exactly one of the main uses of
>the "command" argument in debian/watch.  See docker.io's debian/watch[1]
>for example, where "/bin/sh debian/repack.sh" is what does the
>DFSG-compliance repacking of the orig tarball so that they're cleanly
>repeatable (which is an important property of orig tarballs).
>
>Have you tried comparing the existing orig tarball from the archive to
>the corresponding tarball downloaded via uscan?

debian/copyright also has the ability to affect the tarball that uscan
produces.  It's poorly documented[*], but if you add a Files-Excluded header
to the global stanza in d/copyright, those files will be stripped from the
tarball by uscan.

Cheers,
-Barry

[*] The uscan manpage briefly mentions this but doesn't go into much detail.
This describes the feature better, but it's not as discoverable:
https://wiki.debian.org/UscanEnhancements


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140819093127.3f901...@anarchist.wooz.org

Re: Bug#758013: s3ql autopkg test regression

[Simon McVittie]

On 19/08/14 09:33, Matthias Klose wrote:
[Nikolaus Rath wrote:]
>> That's a bug in the test (race condition) rather than in the program.
>> It's fixed upstream.
> 
> [...] If you don't care
> about the autopkg tests, and if you are not ready to fix these but rather wait
> for the fixes from upstream (and maybe new bugs), then I think it's better to
> drop the autopkg tests.

There are always at least two possible reasons for a failing test: "the
code under test is wrong" or "the test is wrong".

The most important thing is that someone with knowledge of the package
has looked at the failure report and triaged it, i.e. assigned it an
appropriate priority based on their knowledge of the package. It appears
Nikolaus has done this, and it will be dealt with when it's dealt with.
I don't think there's a problem here.

S


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f31a4b.1020...@debian.org

Re: Bug#758013: s3ql autopkg test regression

[Jakub Wilk]

* Matthias Klose , 2014-08-19, 10:33:

Control: severity -1 important


The maintainer decides on the bug severity. Please don't abuse the BTS.

That's a bug in the test (race condition) rather than in the program. 
It's fixed upstream.


Nikolaus, I find this kind of attitude rather disturbing. If you don't 
care about the autopkg tests, and if you are not ready to fix these but 
rather wait for the fixes from upstream (and maybe new bugs), then I 
think it's better to drop the autopkg tests.


Why is it better?

If you want the maintainer to give priority to a bug, you need to give a 
better justification than “I said so”.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140819090239.ga7...@jwilk.net

Re: guardian and django1.7

[Brian May]

On 19 Aug 2014 18:04, "Raphael Hertzog"  wrote:
> Did you fill that new directory with an initial migration generated with
> ./manage.py makemigrations?

Yes, did that, but than I realized I needed to do testapp.

So I did just testapp by itself, but suspect both django apps need to be
done.

At which point I ran out of time :-)

Re: Bug#758013: s3ql autopkg test regression

[Matthias Klose]

Control: severity -1 important

> That's a bug in the test (race condition) rather than in the program.
> It's fixed upstream.

Nikolaus, I find this kind of attitude rather disturbing.  If you don't care
about the autopkg tests, and if you are not ready to fix these but rather wait
for the fixes from upstream (and maybe new bugs), then I think it's better to
drop the autopkg tests.

And replying to the bug report without replying to the maintainer is at least 
odd.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f30be5.7080...@debian.org

Re: guardian and django1.7

[Raphael Hertzog]

Hi,

On Tue, 19 Aug 2014, Brian May wrote:
> > For example, I renamed migrations to south_migrations and created a
> > Django1.7 compliant migrations directory, however still get the same error.

Did you fill that new directory with an initial migration generated with
./manage.py makemigrations?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140819080439.ga1...@x230-buxy.home.ouaza.com

Re: librabbitmq and git

[Michael Fladischer]

On 2014-08-19 01:52, Brian May wrote:
> However, the packaging is in git, and I am not sure how to insert the
> latest upstream version in this git repository.

`git-import-orig `

Cheers,
-- 
Michael Fladischer
Fladi.at



signature.asc
Description: OpenPGP digital signature

Re: librabbitmq and git

[Julian Taylor]

On 19.08.2014 01:52, Brian May wrote:
> Hello,
> 
> I would like to package the latest upstream version of librabbitmq.
> 
> However, the packaging is in git, and I am not sure how to insert the
> latest upstream version in this git repository.
> 
> From debian/control:
> 
> Homepage: https://github.com/alanxz/rabbitmq-c
> Vcs-Git: git://anonscm.debian.org/collab-maint/librabbitmq.git
> 
> Vcs-Browser:
> http://anonscm.debian.org/gitweb/?p=collab-maint/librabbitmq.git
> 
> From debian/copyright:
> 
> Source: https://github.com/alanxz/rabbitmq-c
> 
> I take this to mean I should be downloading the orig.tag.gz from github.
> 
> However, just to make things more interesting, the 5.0 and 5.1 tar.gz
> file from github contains a "sub git repository" (not sure I have used
> correct git terminology here), with invalid relative reference,
> under rabbitmq-c-0.5.1/codegen, which wasn't included in
> librabbitmq_0.5.0.orig.tar.gz
> 
> brian@aquitard:~/tree/debian/unstable/librabbitmq/librabbitmq/codegen$
> cat .git
> gitdir: ../.git/modules/codegen
> brian@aquitard:~/tree/debian/unstable/librabbitmq/librabbitmq/codegen$
> git diff
> fatal: Not a git repository: ../.git/modules/codegen
> 
> So it looks like maybe the librabbitmq_0.5.0.orig.tar.gz was repackaged
> from upstream? Should I do the same thing for 0.5.1?
> 

github.com tag downloads do not include submodules as git archive itself
does not support them.
You will have to download your full tarball from another place than github.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f2f69c.2030...@googlemail.com