Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.maint.python > #9192 > unrolled thread
| Started by | Brian May <bam@debian.org> |
|---|---|
| First post | 2017-01-28 22:50 +0100 |
| Last post | 2017-03-09 12:10 +0100 |
| Articles | 20 on this page of 55 — 14 participants |
Back to article view | Back to linux.debian.maint.python
git-dpm breakage src:faker Brian May <bam@debian.org> - 2017-01-28 22:50 +0100
Re: git-dpm breakage src:faker Brian May <bam@debian.org> - 2017-01-28 23:00 +0100
Re: git-dpm breakage src:faker Scott Kitterman <debian@kitterman.com> - 2017-01-28 23:20 +0100
Re: git-dpm breakage src:faker Brian May <bam@debian.org> - 2017-01-28 23:40 +0100
Re: git-dpm breakage src:faker Scott Kitterman <debian@kitterman.com> - 2017-01-29 00:00 +0100
Re: git-dpm breakage src:faker Arto Jantunen <viiru@debian.org> - 2017-01-29 08:30 +0100
Re: git-dpm breakage src:faker Scott Kitterman <debian@kitterman.com> - 2017-01-29 21:00 +0100
Re: git-dpm breakage src:faker Brian May <bam@debian.org> - 2017-01-30 10:20 +0100
Re: git-dpm breakage src:faker Thomas Goirand <zigo@debian.org> - 2017-02-13 02:30 +0100
Re: git-dpm breakage src:faker Raphael Hertzog <hertzog@debian.org> - 2017-01-29 21:00 +0100
Re: git-dpm breakage src:faker Simon McVittie <smcv@debian.org> - 2017-01-29 21:50 +0100
Re: git-dpm breakage src:faker Brian May <bam@debian.org> - 2017-01-30 07:40 +0100
Moving off of git-dpm (Re: git-dpm breakage src:faker) Barry Warsaw <barry@debian.org> - 2017-01-31 20:30 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Scott Kitterman <debian@kitterman.com> - 2017-01-31 21:00 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Barry Warsaw <barry@debian.org> - 2017-01-31 21:00 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-02-05 06:00 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Scott Kitterman <debian@kitterman.com> - 2017-02-05 08:10 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Barry Warsaw <barry@debian.org> - 2017-02-06 22:30 +0100
Re: Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Ghislain Vaillant <ghisvail@gmail.com> - 2017-02-07 12:10 +0100
Re: Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Simon McVittie <smcv@debian.org> - 2017-02-07 15:10 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Barry Warsaw <barry@debian.org> - 2017-02-07 15:20 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Nikolaus Rath <Nikolaus@rath.org> - 2017-02-09 20:00 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Scott Kitterman <debian@kitterman.com> - 2017-02-10 03:30 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Nikolaus Rath <Nikolaus@rath.org> - 2017-02-10 05:30 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Scott Kitterman <debian@kitterman.com> - 2017-02-10 07:00 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-02-10 11:20 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) kuLa <kula@kulisz.net> - 2017-02-10 11:40 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-02-11 03:10 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Nikolaus Rath <Nikolaus@rath.org> - 2017-02-11 22:10 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Scott Kitterman <debian@kitterman.com> - 2017-02-14 02:50 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-02-14 08:30 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Scott Kitterman <debian@kitterman.com> - 2017-02-14 20:00 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Nikolaus Rath <Nikolaus@rath.org> - 2017-02-16 06:20 +0100
Re: Moving off of git-dpm Piotr Ożarowski <piotr@debian.org> - 2017-02-16 12:40 +0100
Re: Moving off of git-dpm Dimitri John Ledkov <xnox@debian.org> - 2017-02-16 13:50 +0100
Re: Moving off of git-dpm Scott Kitterman <debian@kitterman.com> - 2017-02-16 14:00 +0100
Re: Moving off of git-dpm Barry Warsaw <barry@debian.org> - 2017-02-16 16:00 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-02-10 11:10 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-02-11 02:30 +0100
Re: Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Dmitry Shachnev <mitya57@debian.org> - 2017-02-07 21:20 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-02-05 06:10 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Barry Warsaw <barry@debian.org> - 2017-02-06 22:30 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-02-08 09:10 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-02-13 07:00 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Barry Warsaw <barry@debian.org> - 2017-02-13 17:20 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-02-14 08:00 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-02-14 08:20 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Barry Warsaw <barry@debian.org> - 2017-02-14 17:30 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Arto Jantunen <viiru@debian.org> - 2017-02-14 17:40 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Barry Warsaw <barry@debian.org> - 2017-02-14 17:50 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Simon McVittie <smcv@debian.org> - 2017-02-14 18:00 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Arto Jantunen <viiru@debian.org> - 2017-02-14 18:00 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Brian May <bam@debian.org> - 2017-03-09 11:20 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Vincent Bernat <bernat@debian.org> - 2017-03-09 11:30 +0100
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) Ghislain Vaillant <ghisvail@gmail.com> - 2017-03-09 12:10 +0100
Page 1 of 3 [1] 2 3 Next page →
| From | Brian May <bam@debian.org> |
|---|---|
| Date | 2017-01-28 22:50 +0100 |
| Subject | git-dpm breakage src:faker |
| Message-ID | <t4J2G-6LR-9@gated-at.bofh.it> |
Hello, Looks like somebody applied a change to this git-dpm repo that manually deleted a patch under debian/patches. Instead of using "git-dpm checkout-patched" and then updating. This looks like it has broken git-dpm. How do I fix? Guessing I will have to revert the dodgy commit, and then delete the patch correctly. Regards -- Brian May <bam@debian.org>
[toc] | [next] | [standalone]
| From | Brian May <bam@debian.org> |
|---|---|
| Date | 2017-01-28 23:00 +0100 |
| Message-ID | <t4Jcm-6Pp-7@gated-at.bofh.it> |
| In reply to | #9192 |
Brian May <bam@debian.org> writes: > Hello, > > Looks like somebody applied a change to this git-dpm repo that manually > deleted a patch under debian/patches. > > Instead of using "git-dpm checkout-patched" and then updating. > > This looks like it has broken git-dpm. > > How do I fix? > > Guessing I will have to revert the dodgy commit, and then delete the > patch correctly. Looks like the damage is more extensive then just one patch: [brian:~/tree/debian/python-modules/faker] master ± git-dpm status grep: warning: GREP_OPTIONS is deprecated; please use an alias or script grep: warning: GREP_OPTIONS is deprecated; please use an alias or script NOT UP TO DATE: 'upstream' is newer than listed in debian/.git-dpm Could not find '../fake-factory_0.5.7.orig.tar.gz! Without that file dpkg-source will not work! (Have you forgotten to run git-dpm prepare?) git-dpm: WARNING: guessing from your debian/changelog, your upstream file should be named 'faker_0.7.7.orig.tar.*' but it is named 'fake-factory_0.5.7.orig.tar.gz' grep: warning: GREP_OPTIONS is deprecated; please use an alias or script grep: warning: GREP_OPTIONS is deprecated; please use an alias or script grep: warning: GREP_OPTIONS is deprecated; please use an alias or script grep: warning: GREP_OPTIONS is deprecated; please use an alias or script grep: warning: GREP_OPTIONS is deprecated; please use an alias or script git-dpm: ERROR: Debian branch contains non-debian changes: .bumpversion.cfg .travis.yml CHANGELOG.rst CONTRIBUTING.rst Makefile README.rst docs/coding_style.rst docs/conf.py docs/index.rst faker/__init__.py faker/providers/__init__.py faker/providers/address/en_AU/__init__.py faker/providers/address/en_CA/__init__.py faker/providers/address/en_GB/__init__.py faker/providers/address/en_US/__init__.py faker/providers/address/es/__init__.py faker/providers/address/es_ES/__init__.py faker/providers/address/es_MX/__init__.py faker/providers/address/fa_IR/__init__.py faker/providers/address/fi_FI/__init__.py faker/providers/address/fr_CH/__init__.py faker/providers/address/fr_FR/__init__.py faker/providers/address/hi_IN/__init__.py faker/providers/address/it_IT/__init__.py faker/providers/address/ja_JP/__init__.py faker/providers/address/ko_KR/__init__.py faker/providers/address/ne_NP/__init__.py faker/providers/address/nl_BE/__init__.py faker/providers/address/no_NO/__init__.py faker/providers/address/pl_PL/__init__.py faker/providers/address/pt_BR/__init__.py faker/providers/address/ru_RU/__init__.py faker/providers/address/sl_SI/__init__.py faker/providers/address/uk_UA/__init__.py faker/providers/address/zh_CN/__init__.py faker/providers/address/zh_TW/__init__.py faker/providers/barcode/__init__.py faker/providers/color/__init__.py faker/providers/color/uk_UA/__init__.py faker/providers/company/fr_CH/__init__.py faker/providers/company/pt_BR/__init__.py faker/providers/company/ru_RU/__init__.py faker/providers/credit_card/__init__.py faker/providers/currency/__init__.py faker/providers/date_time/__init__.py faker/providers/file/__init__.py faker/providers/internet/__init__.py faker/providers/internet/fr_CH/__init__.py faker/providers/internet/fr_FR/__init__.py faker/providers/internet/ru_RU/__init__.py faker/providers/internet/uk_UA/__init__.py faker/providers/internet/zh_CN/__init__.py faker/providers/job/__init__.py faker/providers/job/fr_CH/__init__.py faker/providers/job/hr_HR/__init__.py faker/providers/job/zh_TW/__init__.py faker/providers/misc/__init__.py faker/providers/person/__init__.py faker/providers/person/de_AT/__init__.py faker/providers/person/de_DE/__init__.py faker/providers/person/dk_DK/__init__.py faker/providers/person/en/__init__.py faker/providers/person/en_GB/__init__.py faker/providers/person/en_US/__init__.py faker/providers/person/fa_IR/__init__.py faker/providers/person/fr_CH/__init__.py faker/providers/person/ko_KR/__init__.py faker/providers/person/pt_BR/__init__.py faker/providers/person/ru_RU/__init__.py faker/providers/person/uk_UA/__init__.py faker/providers/person/zh_CN/__init__.py faker/providers/phone_number/en_US/__init__.py faker/providers/phone_number/fa_IR/__init__.py faker/providers/phone_number/fr_CH/__init__.py faker/providers/phone_number/nl_BE/__init__.py faker/providers/phone_number/zh_TW/__init__.py faker/providers/profile/__init__.py faker/providers/python/__init__.py faker/providers/ssn/__init__.py faker/providers/ssn/en_CA/__init__.py faker/providers/ssn/fr_CH/__init__.py faker/providers/ssn/hr_HR/__init__.py faker/providers/ssn/ko_KR/__init__.py faker/providers/ssn/nl_BE/__init__.py faker/providers/ssn/ru_RU/__init__.py faker/providers/ssn/sv_SE/__init__.py faker/providers/ssn/uk_UA/__init__.py faker/tests/__init__.py faker/tests/hr_HR/__init__.py faker/tests/no_NO/__init__.py faker/tests/pt_BR/__init__.py faker/utils/datasets.py readthedocs.yml setup.py 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. In this case I suspect the latest upstream was imported and then the package renamed without using any of the git-dpm tools or updating debian/.git-dpm. So I am inclined just to delete debian/.git-dpm in the interests of getting a fix for the RC bugs as fast as possible. -- Brian May <bam@debian.org>
[toc] | [prev] | [next] | [standalone]
| From | Scott Kitterman <debian@kitterman.com> |
|---|---|
| Date | 2017-01-28 23:20 +0100 |
| Message-ID | <t4JvH-7bG-11@gated-at.bofh.it> |
| In reply to | #9193 |
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? Scott K
[toc] | [prev] | [next] | [standalone]
| From | Brian May <bam@debian.org> |
|---|---|
| Date | 2017-01-28 23:40 +0100 |
| Message-ID | <t4JP4-7iL-23@gated-at.bofh.it> |
| In reply to | #9194 |
Scott Kitterman <debian@kitterman.com> 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. -- Brian May <bam@debian.org>
[toc] | [prev] | [next] | [standalone]
| From | Scott Kitterman <debian@kitterman.com> |
|---|---|
| Date | 2017-01-29 00:00 +0100 |
| Message-ID | <t4K8q-7pZ-21@gated-at.bofh.it> |
| In reply to | #9195 |
On Sunday, January 29, 2017 09:39:10 AM Brian May wrote: > Scott Kitterman <debian@kitterman.com> 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? Scott K
[toc] | [prev] | [next] | [standalone]
| From | Arto Jantunen <viiru@debian.org> |
|---|---|
| Date | 2017-01-29 08:30 +0100 |
| Message-ID | <t4S5X-46i-3@gated-at.bofh.it> |
| In reply to | #9197 |
Scott Kitterman <debian@kitterman.com> writes: > On Sunday, January 29, 2017 09:39:10 AM Brian May wrote: >> Scott Kitterman <debian@kitterman.com> 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. -- Arto Jantunen
[toc] | [prev] | [next] | [standalone]
| From | Scott Kitterman <debian@kitterman.com> |
|---|---|
| Date | 2017-01-29 21:00 +0100 |
| Message-ID | <t53NL-2Mz-5@gated-at.bofh.it> |
| In reply to | #9198 |
On January 29, 2017 2:17:16 AM EST, Arto Jantunen <viiru@debian.org> wrote: >Scott Kitterman <debian@kitterman.com> writes: > >> On Sunday, January 29, 2017 09:39:10 AM Brian May wrote: >>> Scott Kitterman <debian@kitterman.com> 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
[toc] | [prev] | [next] | [standalone]
| From | Brian May <bam@debian.org> |
|---|---|
| Date | 2017-01-30 10:20 +0100 |
| Message-ID | <t5ghY-2bl-13@gated-at.bofh.it> |
| In reply to | #9200 |
Scott Kitterman <debian@kitterman.com> writes: > OK. Where do I find documentation to give this a try? I used the following documentation: http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.html -- Brian May <bam@debian.org>
[toc] | [prev] | [next] | [standalone]
| From | Thomas Goirand <zigo@debian.org> |
|---|---|
| Date | 2017-02-13 02:30 +0100 |
| Message-ID | <tadCN-5dN-3@gated-at.bofh.it> |
| In reply to | #9198 |
On 01/29/2017 08:17 AM, Arto Jantunen wrote: > Scott Kitterman <debian@kitterman.com> writes: >> 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. You wish! git-dpm just scrap any patch header lines you may manually edit. This alone is a good reason to get out of it quickly.
[toc] | [prev] | [next] | [standalone]
| From | Raphael Hertzog <hertzog@debian.org> |
|---|---|
| Date | 2017-01-29 21:00 +0100 |
| Message-ID | <t53NL-2Mz-3@gated-at.bofh.it> |
| In reply to | #9195 |
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/
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2017-01-29 21:50 +0100 |
| Message-ID | <t54A9-3js-5@gated-at.bofh.it> |
| In reply to | #9199 |
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
[...] Those options 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
[toc] | [prev] | [next] | [standalone]
| From | Brian May <bam@debian.org> |
|---|---|
| Date | 2017-01-30 07:40 +0100 |
| Message-ID | <t5dN7-Bp-1@gated-at.bofh.it> |
| In reply to | #9199 |
Raphael Hertzog <hertzog@debian.org> 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 <bam@debian.org>
[toc] | [prev] | [next] | [standalone]
| From | Barry Warsaw <barry@debian.org> |
|---|---|
| Date | 2017-01-31 20:30 +0100 |
| Subject | Moving off of git-dpm (Re: git-dpm breakage src:faker) |
| Message-ID | <t5MhQ-4zG-7@gated-at.bofh.it> |
| In reply to | #9195 |
On Jan 29, 2017, at 09:39 AM, Brian May wrote: >I would think "gbp pq" is the most popular. I've used it on some of my non-team packages and while it takes a little getting used to for the standard git-dpm workflow, it's been mostly fine. What I'd really like to see is a page like https://wiki.debian.org/Python/GitPackaging for a non-git-dpm workflow. (The page itself could probably use a bit of gardening anyway.) Specifically, I'd like to see guidance on any tasks which are different for git-pq (or non-git-dpm as the case may be). I'd suggest cloning that page instead of modify that page to cover both cases. Edit the clone as if it were the opinionated view of just using gbp tools and gbp-pq. The page should also have instructions on opportunistically switching away from git-dpm. Then we can start to use those instructions in anger and add any other recommendations for corner cases. Once we have enough experience with gpb-pq throughout the team, we can consider making an official switch. Cheers, -Barry
[toc] | [prev] | [next] | [standalone]
| From | Scott Kitterman <debian@kitterman.com> |
|---|---|
| Date | 2017-01-31 21:00 +0100 |
| Subject | Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) |
| Message-ID | <t5MKS-4Js-11@gated-at.bofh.it> |
| In reply to | #9207 |
On Tuesday, January 31, 2017 02:23:29 PM Barry Warsaw wrote: > On Jan 29, 2017, at 09:39 AM, Brian May wrote: > >I would think "gbp pq" is the most popular. > > I've used it on some of my non-team packages and while it takes a little > getting used to for the standard git-dpm workflow, it's been mostly fine. > > What I'd really like to see is a page like > https://wiki.debian.org/Python/GitPackaging for a non-git-dpm workflow. > (The page itself could probably use a bit of gardening anyway.) > Specifically, I'd like to see guidance on any tasks which are different for > git-pq (or non-git-dpm as the case may be). > > I'd suggest cloning that page instead of modify that page to cover both > cases. Edit the clone as if it were the opinionated view of just using gbp > tools and gbp-pq. The page should also have instructions on > opportunistically switching away from git-dpm. > > Then we can start to use those instructions in anger and add any other > recommendations for corner cases. Once we have enough experience with > gpb-pq throughout the team, we can consider making an official switch. We should probably be thinking in terms of post-release for this change. During the pre-release freeze, the release team doesn't typically allow changes that extraneous to fixing the specific issue they are letting a package into Testing to fix. The .git-dpm file is shipped in the package, so if we drop git-dpm, we're going to have to deal with getting .git-dpm removals through the release team for any package that needs update during the freeze. That will also give us time to make sure we have a proper migration strategy and sufficient documentation. Scott K
[toc] | [prev] | [next] | [standalone]
| From | Barry Warsaw <barry@debian.org> |
|---|---|
| Date | 2017-01-31 21:00 +0100 |
| Subject | Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) |
| Message-ID | <t5MKS-4Js-17@gated-at.bofh.it> |
| In reply to | #9208 |
On Jan 31, 2017, at 02:51 PM, Scott Kitterman wrote: >We should probably be thinking in terms of post-release for this change. Oh, definitely +1 -Barry
[toc] | [prev] | [next] | [standalone]
| From | Brian May <bam@debian.org> |
|---|---|
| Date | 2017-02-05 06:00 +0100 |
| Subject | Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) |
| Message-ID | <t7n5E-2ww-9@gated-at.bofh.it> |
| In reply to | #9208 |
Scott Kitterman <debian@kitterman.com> writes: > We should probably be thinking in terms of post-release for this change. > During the pre-release freeze, the release team doesn't typically allow > changes that extraneous to fixing the specific issue they are letting a > package into Testing to fix. The .git-dpm file is shipped in the package, so > if we drop git-dpm, we're going to have to deal with getting .git-dpm removals > through the release team for any package that needs update during the > freeze. The .git-dpm file is only shipped with the Debian source package, and AFAIK has no meaning outside git. So it is a useless file for the Debian source package. There should be no impact whatsoever in removing it, and you could even argue that it was a bug to distribute it in the Debian source in the fist place. > That will also give us time to make sure we have a proper migration strategy > and sufficient documentation. That may be a better reason. Hence the reason I suggested not doing a mass migration of all packages at once (at least for now) but to update the package when it otherwise needs updating. -- Brian May <bam@debian.org>
[toc] | [prev] | [next] | [standalone]
| From | Scott Kitterman <debian@kitterman.com> |
|---|---|
| Date | 2017-02-05 08:10 +0100 |
| Subject | Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) |
| Message-ID | <t7p7r-46L-3@gated-at.bofh.it> |
| In reply to | #9215 |
On Sunday, February 05, 2017 03:59:37 PM Brian May wrote: > Scott Kitterman <debian@kitterman.com> writes: > > We should probably be thinking in terms of post-release for this change. > > During the pre-release freeze, the release team doesn't typically allow > > changes that extraneous to fixing the specific issue they are letting a > > package into Testing to fix. The .git-dpm file is shipped in the package, > > so if we drop git-dpm, we're going to have to deal with getting .git-dpm > > removals through the release team for any package that needs update > > during the freeze. > > The .git-dpm file is only shipped with the Debian source package, and > AFAIK has no meaning outside git. So it is a useless file for the Debian > source package. There should be no impact whatsoever in removing it, and > you could even argue that it was a bug to distribute it in the Debian > source in the fist place. The opinion of the release team matters here more than yours or mine. Before doing anything pre-release, we ought to get a reading from them. > > That will also give us time to make sure we have a proper migration > > strategy and sufficient documentation. > > That may be a better reason. > > Hence the reason I suggested not doing a mass migration of all packages > at once (at least for now) but to update the package when it otherwise > needs updating. Experimentation with a few packages to prepare for a migration and make sure the documentation is good, is fine. We really ought to switch for real all at once like we did for svn -> git. It's not much of a team repository without a consistent approach for VCS use. Scott K
[toc] | [prev] | [next] | [standalone]
| From | Barry Warsaw <barry@debian.org> |
|---|---|
| Date | 2017-02-06 22:30 +0100 |
| Subject | Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) |
| Message-ID | <t7Z1g-1XE-17@gated-at.bofh.it> |
| In reply to | #9217 |
On Feb 05, 2017, at 02:07 AM, Scott Kitterman wrote: >Experimentation with a few packages to prepare for a migration and make sure >the documentation is good, is fine. We really ought to switch for real all >at once like we did for svn -> git. It's not much of a team repository >without a consistent approach for VCS use. +1 -Barry
[toc] | [prev] | [next] | [standalone]
| From | Ghislain Vaillant <ghisvail@gmail.com> |
|---|---|
| Date | 2017-02-07 12:10 +0100 |
| Subject | Re: Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) |
| Message-ID | <t8bON-24f-13@gated-at.bofh.it> |
| In reply to | #9217 |
I know the discussion is leaning towards replacing usage of git-dpm with gbp-pq. I have nothing against it but, since we are talking about solutions for a git-centric workflow, has anyone considered the dgit- maint-merge workflow [1]? It is very well documented and would simplify team-packaging policies a good deal. Assuming dgit-maint-merge were widely adopted, packaging policies would only need to cover team-specific details, such as infrastructure or communication channels for sponsorship, and then reference the dgit-maint-merge manpages for the packaging workflow. [1] https://www.mankier.com/7/dgit-maint-merge Best regards, Ghis
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2017-02-07 15:10 +0100 |
| Subject | Re: Re: Moving off of git-dpm (Re: git-dpm breakage src:faker) |
| Message-ID | <t8eD0-3TA-17@gated-at.bofh.it> |
| In reply to | #9226 |
On Tue, 07 Feb 2017 at 10:47:00 +0000, Ghislain Vaillant wrote:
> I know the discussion is leaning towards replacing usage of git-dpm
> with gbp-pq. I have nothing against it but, since we are talking about
> solutions for a git-centric workflow, has anyone considered the dgit-
> maint-merge workflow?
The dgit-maint-merge man page starts with some axioms:
The workflow makes the following opinionated assumptions:
· Git histories should be the non-linear histories produced by
git-merge(1), preserving all information about divergent
development that was later brought together.
I don't think that is actually a useful model of distro development.
I'm sure the rest of dgit-maint-merge(7) is a perfectly reasonable
workflow when you start from its assumptions, but I think they're
the wrong assumptions.
I think the downstream maintainer job in vendors like Debian (and Red
Hat, etc.) is essentially a rebasing patch series, whether we represent
it like that in git or not:
* we track an upstream version, which we treat as somehow canonical[1]
* we track what the downstream does as divergence from that upstream
version, and only secondarily as a product in its own right (this is
a core assumption in the design of all the non-native dpkg-source
formats, and also SRPMs, so this is clearly something that has been
considered important to downstreams)
* when we import a new upstream version, we adjust our divergence to
apply on top of that new version
* some of the divergence is vendor-specific and we will never upstream it
(for example adjusting paths/defaults to meet Debian Policy)
* some of the divergence is intended to go upstream, although our
upstreams don't always apply in-principle-upstreamable changes
as fast as we'd like them to; when it does get applied, it is often
applied to their current development branch (like a git-cherry-pick)
rather than being merged, and even if we send Github pull requests
or similar, the upstream will want them to be based on some upstream
branch and not on Debian's
* in Debian's case, even if they want to apply all the patches we propose
to their upstream source, our upstreams will never want to `git merge`
the contents of our VCS, because they usually don't want to merge
debian/ (and in fact we actively recommend that they don't)
That's why, although I find dgit an interesting idea, I think
dgit-maint-merge(7) is a trap. If I use dgit at all, it'll be
dgit-maint-gbp(7) or similar.
[Conflict-of-interest disclaimer: I am a happy user of gbp-pq for every
patched package I maintain, except for tap.py and pkg-gnome svn. I would
love to see gbp-pq adopted by DPMT so I can use it for tap.py, and
when pkg-gnome finally moves from svn to git, given the overlap among
active maintainers between pkg-{systemd,utopia,gnome}, I suspect they
are going to use gbp-pq like pkg-systemd and pkg-utopia do.
I also seriously considered maintaining tap.py outside DPMT as a way
to avoid git-dpm.]
Regards,
S
[1] but in most cases not Canonical :-)
[toc] | [prev] | [next] | [standalone]
Page 1 of 3 [1] 2 3 Next page →
Back to top | Article view | linux.debian.maint.python
csiph-web