Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1279010 > unrolled thread

Bug#948844: debmake: option for git maintained packages

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#948844: debmake: option for git maintained packages Osamu Aoki <osamu@debian.org> - 2026-01-19 15:40 +0100
    Bug#948844: debmake: option for git maintained packages Sean Whitton <spwhitton@spwhitton.name> - 2026-01-19 22:20 +0100
      Bug#948844: debmake: option for git maintained packages Osamu Aoki <osamu@debian.org> - 2026-01-20 08:20 +0100
        Bug#948844: debmake: option for git maintained packages Sean Whitton <spwhitton@spwhitton.name> - 2026-01-24 20:30 +0100
          Bug#948844: debmake: option for git maintained packages Osamu Aoki <osamu@debian.org> - 2026-01-25 22:30 +0100
    Bug#948844: debmake: option for git maintained packages Osamu Aoki <osamu@debian.org> - 2026-01-20 02:10 +0100
      Bug#948844: debmake: option for git maintained packages Sean Whitton <spwhitton@spwhitton.name> - 2026-01-24 20:30 +0100

#1279010 — Bug#948844: debmake: option for git maintained packages

Hi,

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948844

> > I am following the the "When upstream tags releases in git" section of
> > dgit-maint-merge(7) and when I get to the "Now go ahead and
> > Debianise..." section I'd like to be able to run debmake, but it's
> > expecting the source dir to have a particular name and the orig tarball
> > to exist.

The last part is interesting point as usability.  Otto pointed out this in 
https://bugs.debian.org/1090069

All you needed was adding -T/--tar option.

When I recently updated debmake to 5.0.0, I addressed this hard to find solution
by prompting user to activate this option instead of stop processing.  So I
closed #1090069.

I am keeping this bug report open for better support of dgit which I use it too.

Considering many packaging workflows (gbp is still widely used), I am inclined
to add comment to required template.

I need one clarification:

For non-native package, dgit-maint-merge(7) recommend not to create
debian/source/local-options but create debian/source/options containing:

  auto-commit

I am following this with my own actual packaging but not with debmake template.

I had vague impression that use of debian/source/options is problematic for
NMUers who doesn't use the same set up for building.  (Is this for GBP-type
workflow?)

Please confirm this auto-commit for dgit-maint-merge must be in
debian/source/options and not in debian/source/local-options.

What about other dgit work flow.  How incompatible are debian/source/local-
options.  I understand dgit warn it but I want template file comment should be
in line with expectation.

I think as long as settings are commented out, debian/source/local-options file
itself can be there for dgit.  Am I correct?

Let me know.

Osamu

[toc] | [next] | [standalone]

#1279052

Hello Osamu, hope you are doing good.

Osamu Aoki [19/Jan 11:33pm +09] wrote:
> I need one clarification:
>
> For non-native package, dgit-maint-merge(7) recommend not to create
> debian/source/local-options but create debian/source/options containing:
>
>   auto-commit
>
> I am following this with my own actual packaging but not with debmake template.
>
> I had vague impression that use of debian/source/options is problematic for
> NMUers who doesn't use the same set up for building.  (Is this for GBP-type
> workflow?)
>
> Please confirm this auto-commit for dgit-maint-merge must be in
> debian/source/options and not in debian/source/local-options.
>
> What about other dgit work flow.  How incompatible are debian/source/local-
> options.  I understand dgit warn it but I want template file comment should be
> in line with expectation.
>
> I think as long as settings are commented out, debian/source/local-options file
> itself can be there for dgit.  Am I correct?

Actually, debian/source/local-options is never compatible with dgit or
tag2upload.  Only debian/source/options is acceptable.  So I would
suggest never creating that file.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#1279085

Hi,

On Mon, 2026-01-19 at 21:16 +0000, Sean Whitton wrote:
> Hello Osamu, hope you are doing good.
> 
> Actually, debian/source/local-options is never compatible with dgit or
> tag2upload.  Only debian/source/options is acceptable.  So I would
> suggest never creating that file.

Got your point.  But I have question.

(I am going to add these templates with .ex suffix, so there should be no actual
issue.)

I am curious about extent of your "never compatible" statement.

According to dpkg-source(1)manpage , lines preceded by "#" are ignored for 
both debian/source/options and debian/source/local-options.

Does dgit workflow chokes on these files having all lines preceded by "#" ?

Osamu

[toc] | [prev] | [next] | [standalone]

#1279652

[Multipart message — attachments visible in raw view] — view raw

Hello,

Osamu Aoki [20/Jan  4:16pm +09] wrote:
> Hi,
>
> On Mon, 2026-01-19 at 21:16 +0000, Sean Whitton wrote:
>> Hello Osamu, hope you are doing good.
>>
>> Actually, debian/source/local-options is never compatible with dgit or
>> tag2upload.  Only debian/source/options is acceptable.  So I would
>> suggest never creating that file.
>
> Got your point.  But I have question.
>
> (I am going to add these templates with .ex suffix, so there should be no actual
> issue.)
>
> I am curious about extent of your "never compatible" statement.
>
> According to dpkg-source(1)manpage , lines preceded by "#" are ignored for
> both debian/source/options and debian/source/local-options.
>
> Does dgit workflow chokes on these files having all lines preceded by "#" ?

No, the debian/source/local-options file can never exist no matter its
contents.

The reason is that its existence breaks dgit's basic design principle:
there is no difference between the git tree and the exported source
package.  local-options only exists in git and not in the exported
source package, by definition.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#1279776

Hi,

On Sat, 2026-01-24 at 18:55 +0000, Sean Whitton wrote:
> 
> No, the debian/source/local-options file can never exist no matter its
> contents.
> 
> The reason is that its existence breaks dgit's basic design principle:
> there is no difference between the git tree and the exported source
> package.  local-options only exists in git and not in the exported
> source package, by definition.

I see and noted.  (Also for single-patch as recommended practice in d/options)

Thanks

Osamu

[toc] | [prev] | [next] | [standalone]

#1279070

Hi,

I have some second thought about how to use debian/source/local-options and
debian/source/options (see below quote)

Git usage and packaging are coupled.

* GBP (unapply-patches VCS)
debian/source/local-options with unapply-patches

* dgit (dgit-maint-merge: patch applied VCS)
debian/source/options with auto-commit

single-debian-patch in debian/source/options ... This seems optional and taste
issue as long as auto-commit is used.  Am I wrong?

NMUer complication issue is for GBP use case with unapply-patches when it is
used in debian/source/options instead.

So debmake need to update it to cope with this new style of git usage with dgit-
maint-merge.

I also think as long as lines are commented out with leading "#", having file
such as debian/source/local-options and debian/source/options causes no
negatives.

Considering debmake's age and dgit's age, I need to review this situation with
care.

Osamu

On Mon, 2026-01-19 at 23:33 +0900, Osamu Aoki wrote:
> Hi,
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948844
> ...
> I am keeping this bug report open for better support of dgit which I use it
> too.
> 
> Considering many packaging workflows (gbp is still widely used), I am inclined
> to add comment to required template.
> 
> I need one clarification:
> 
> For non-native package, dgit-maint-merge(7) recommend not to create
> debian/source/local-options but create debian/source/options containing:
> 
>   auto-commit
> 
> I am following this with my own actual packaging but not with debmake
> template.
> 
> I had vague impression that use of debian/source/options is problematic for
> NMUers who doesn't use the same set up for building.  (Is this for GBP-type
> workflow?)
> 
> Please confirm this auto-commit for dgit-maint-merge must be in
> debian/source/options and not in debian/source/local-options.
> 
> What about other dgit work flow.  How incompatible are debian/source/local-
> options.  I understand dgit warn it but I want template file comment should be
> in line with expectation.
> 
> I think as long as settings are commented out, debian/source/local-options
> file
> itself can be there for dgit.  Am I correct?
> 
> Let me know.
> 
> Osamu

[toc] | [prev] | [next] | [standalone]

#1279651

[Multipart message — attachments visible in raw view] — view raw

Hello,

Osamu Aoki [20/Jan 10:03am +09] wrote:
> Hi,
>
> I have some second thought about how to use debian/source/local-options and
> debian/source/options (see below quote)
>
> Git usage and packaging are coupled.
>
> * GBP (unapply-patches VCS)
> debian/source/local-options with unapply-patches
>
> * dgit (dgit-maint-merge: patch applied VCS)
> debian/source/options with auto-commit
>
> single-debian-patch in debian/source/options ... This seems optional and taste
> issue as long as auto-commit is used.  Am I wrong?

Sometimes patches are removed.  Without single-debian-patch, the patch
queue will only get longer and longer -- there'll be both the patch and
another one later in the series that reverts it.

Also, single-debian-patch makes it clear to someone looking at the
source package that the source of truth is elsewhere.

-- 
Sean Whitton

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web