Re: git-dpm breakage src:faker

2017-01-29 Thread Brian May 
Raphael Hertzog  writes:

> You don't need that. dpkg-buildpackage unapplies them automatically after
> the build if it has applied them. If they were already applied before the
> build, then it leaves them applied.

Guess it depends how you build the package. I have been using:

gbp buildpackage "--git-builder=debuild -i -I -S"

In order to get a *.dsc file that sbuild can use. This command appears
to leave the patches applied. Guess I should investigate changing that
line to somethine else...
-- 
Brian May

egg-info and Debian-specific submodule packages

2017-01-29 Thread Luke W Faraone 
Hello,

In bug #744741[1], we have a report where a lack of ``egg-info`` metadata breaks
both ``pip``'s installation detection and packages that use ``pkg_resources`` to
discover dependencies.

Usually, the answer would be simple: ship the ``egg-info`` metadata as part of
the package. But PySide is distributed upstream[2] and via PyPI[3] as one
monolithic package. Debian splits that out into 14 packages, ``python-
pyside.phonon``, ``python-pyside.qtcore``, ``python-pyside.qtdeclarative``, etc.

So, should we ship the egg-info files in a common package, as Barry
suggested[4], and make each of the submodules depend on it? This has the
unfortunate side-effect of breaking third-party packages that attempt to detect
whether PySide is installed.

Alternatively, we could only distribute it as part of ``python-pyside`` (a
metapackage), but this would require patching to some Debian-distributed
packages such as ``yubikey-piv-manager``.

A third option would be to ask upstream to split out the packages as we have
done -- that would resolve the conflict in this instance, but not the general
issue, and would probably take a lot of effort (or be rebuffed).

[1]: https://bugs.debian.org/744741
[2]: https://download.qt.io/official_releases/pyside/
[3]: https://pypi.python.org/pypi/PySide
[4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744741#36

  -- Luke Faraone

signature.asc
Description: This is a digitally signed message part

Re: git-dpm breakage src:faker

2017-01-29 Thread Simon McVittie 
On Sun, 29 Jan 2017 at 20:50:48 +0100, Raphael Hertzog wrote:
> On Sun, 29 Jan 2017, Brian May wrote:
> >   3. Update debian/source/options with "unapply-patches" (anything else?).
> 
> You don't need that. dpkg-buildpackage unapplies them automatically after
> the build if it has applied them. If they were already applied before the
> build, then it leaves them applied.

Not only do you not need that, it isn't even allowed:

   --no-unapply-patches, --unapply-patches
  [...] Thoseoptions are only allowed in
  debian/source/local-options   so   that   all  generated  source
  packages have the same behavior by default.

See flatpak, dbus, ioquake3, or basically anything else I maintain
if you need typical examples of gbp-pq packages that sometimes or always
have patches.

(I would be delighted to switch src:tap.py to gbp-pq if you want an example
of migration.)

S

Re: git-dpm breakage src:faker

2017-01-29 Thread Scott Kitterman 


On January 29, 2017 2:17:16 AM EST, Arto Jantunen  wrote:
>Scott Kitterman  writes:
>
>> On Sunday, January 29, 2017 09:39:10 AM Brian May wrote:
>>> Scott Kitterman  writes:
>>> > On Sunday, January 29, 2017 08:54:57 AM Brian May wrote:
>>> >> Can we switch away from git-dpm yet? Sure this is most likely
>user
>>> >> error, however I want to try to solve an RC bug, not fix broken
>git-dpm
>>> >> first.
>>> > 
>>> > Much like the switch from svn to git, I think we need an agreed
>new
>>> > workflow and tools and a migration plan.
>>> > 
>>> > What do you propose?
>>> 
>>> I would think "gbp pq" is the most popular.
>>> 
>>> I think something like:
>>> 
>>> * Don't touch existing packages just for the sake of doing so.
>>> * Next time you do need to update a package with a debian/.git-dpm:
>>>   1. Delete debian/.git-dpm.
>>>   2. Unapply all patches and commit (not sure what the easiest way
>is)
>>>   3. Update debian/source/options with "unapply-patches" (anything
>else?).
>>> * If you encounter a package without debian/.git-dpm, don't re-add
>it.
>>> * Don't push the gbp pq patches queue branch.
>>
>> I've never used it.
>>
>> Does that then result in one big undifferentiated mass of diff in the
>source 
>> package?
>
>No, it results in separate patches with their headers intact in the
>source package. I assume git-dpm (which I've never used) produces the
>same end result.
>
>The git repository is of course different, with gbp pq carrying the
>patches as patches in the packaging branch, and git-dpm having separate
>magical patch branches.


OK. Where do I find documentation to give this a try?

Scott K

Re: git-dpm breakage src:faker

2017-01-29 Thread Raphael Hertzog 
On Sun, 29 Jan 2017, Brian May wrote:
>   3. Update debian/source/options with "unapply-patches" (anything else?).

You don't need that. dpkg-buildpackage unapplies them automatically after
the build if it has applied them. If they were already applied before the
build, then it leaves them applied.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/