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

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

Bug#1120289: trixie-pu: magit/4.3.5-1+deb13u1

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

Contents

  Bug#1120289: trixie-pu: magit/4.3.5-1+deb13u1 Xiyue Deng <manphiz@gmail.com> - 2025-11-07 02:20 +0100
    Bug#1120289: trixie-pu: magit/4.3.5-1+deb13u1 "Adam D. Barratt" <adam@adam-barratt.org.uk> - 2025-11-07 20:40 +0100
      Bug#1120289: trixie-pu: magit/4.3.5-1+deb13u1 Xiyue Deng <manphiz@gmail.com> - 2025-11-08 07:00 +0100
        Bug#1120289: trixie-pu: magit/4.3.5-1+deb13u1 "Adam D. Barratt" <adam@adam-barratt.org.uk> - 2025-11-08 23:00 +0100
          Bug#1120289: trixie-pu: magit/4.3.5-1+deb13u1 Xiyue Deng <manphiz@gmail.com> - 2025-11-09 06:00 +0100
            Bug#1120289: trixie-pu: magit/4.3.5-1+deb13u1 "Adam D. Barratt" <adam@adam-barratt.org.uk> - 2025-11-09 11:30 +0100
              Bug#1120289: trixie-pu: magit/4.3.5-1+deb13u1 "Adam D. Barratt" <adam@adam-barratt.org.uk> - 2025-11-10 07:30 +0100
    Bug#1120289: trixie-pu: magit/4.3.5-1+deb13u1 Johannes Schauer Marin Rodrigues <josch@debian.org> - 2025-11-10 09:20 +0100
      Bug#1120289: trixie-pu: magit/4.3.5-1+deb13u1 Xiyue Deng <manphiz@gmail.com> - 2025-11-10 09:40 +0100
        Bug#1120289: trixie-pu: magit/4.3.5-1+deb13u1 Johannes Schauer Marin Rodrigues <josch@debian.org> - 2025-11-10 11:10 +0100
          Bug#1120289: trixie-pu: magit/4.3.5-1+deb13u1 Xiyue Deng <manphiz@gmail.com> - 2025-11-10 14:10 +0100
            Bug#1120289: trixie-pu: magit/4.3.5-1+deb13u1 Johannes Schauer Marin Rodrigues <josch@debian.org> - 2025-11-10 14:50 +0100
              Bug#1120289: trixie-pu: magit/4.3.5-1+deb13u1 Xiyue Deng <manphiz@gmail.com> - 2025-11-11 02:10 +0100
                Bug#1120289: trixie-pu: magit/4.3.5-1+deb13u1 Johannes Schauer Marin Rodrigues <josch@debian.org> - 2025-11-11 06:40 +0100
    Bug#1120289: trixie-pu: magit/4.3.5-1+deb13u1 Johannes Schauer Marin Rodrigues <josch@debian.org> - 2025-11-11 09:50 +0100
    Bug#1120289: trixie-pu: magit/4.3.5-1+deb13u1 Johannes Schauer Marin Rodrigues <josch@debian.org> - 2025-11-11 14:00 +0100
      Bug#1120289: trixie-pu: magit/4.3.5-1+deb13u1 "Adam D. Barratt" <adam@adam-barratt.org.uk> - 2025-11-11 18:10 +0100
        Bug#1120289: trixie-pu: magit/4.3.5-1+deb13u1 Johannes Schauer Marin Rodrigues <josch@debian.org> - 2025-11-11 22:20 +0100

#1269360 — Bug#1120289: trixie-pu: magit/4.3.5-1+deb13u1

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

Package: release.debian.org
Severity: normal
Tags: trixie
X-Debbugs-Cc: debian-emacsen@lists.debian.org, Barak A. Pearlmutter <bap@debian.org>, Rémi Vanicat <vanicat@debian.org>, Timo Lindfors <timo.lindfors@iki.fi>, Aymeric Agon-Rambosson <aymeric.agon@yandex.com>
Control: affects -1 + src:magit
User: release.debian.org@packages.debian.org
Usertags: pu

[ Reason ]

This update fixes bug#1120049 which affects user to invoke some magit
functions from a dired buffer.

[ Impact ]

Without the fix users will be unable to run some functionality of magit
due to some upstream files not shipped as intended.

[ Tests ]

I have manually verified that the fix works.

[ Risks ]

This risk is minimal: it ships a missing file.  The debdiff includes
another minimal d/gbp.conf change that should not cause any issue.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [ ] the issue is verified as fixed in unstable

Note: this fix is still pending for unstable due to a newer magit
version is awaiting emacs-cond-let to leave the NEW queue.  This should
not block the fix in stable IMHO.

-- 
Regards,
Xiyue Deng

[toc] | [next] | [standalone]

#1269456

Control: tags -1 + moreinfo

On Thu, 2025-11-06 at 17:16 -0800, Xiyue Deng wrote:

> This update fixes bug#1120049 which affects user to invoke some magit
> functions from a dired buffer.

[...]
>   [ ] the issue is verified as fixed in unstable
> 
> Note: this fix is still pending for unstable due to a newer magit
> version is awaiting emacs-cond-let to leave the NEW queue.  This
> should not block the fix in stable IMHO.

I'm afraid that we do want fixes to have been made to unstable first.
Please remove the moreinfo tag once that's happened.

Regards,

Adam

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

#1269496

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

Control: tags -1 - moreinfo

Hi Adam,

"Adam D. Barratt" <adam@adam-barratt.org.uk> writes:

> Control: tags -1 + moreinfo
>
> On Thu, 2025-11-06 at 17:16 -0800, Xiyue Deng wrote:
>
>> This update fixes bug#1120049 which affects user to invoke some magit
>> functions from a dired buffer.
>
> [...]
>>   [ ] the issue is verified as fixed in unstable
>> 
>> Note: this fix is still pending for unstable due to a newer magit
>> version is awaiting emacs-cond-let to leave the NEW queue.  This
>> should not block the fix in stable IMHO.
>
> I'm afraid that we do want fixes to have been made to unstable first.
> Please remove the moreinfo tag once that's happened.
>

Ack.  I have just pushed 4.3.8-2 to unstable which included the fix (I
was hoping that the NEW queue processing would happen soon, but well).
I think this should satisfy the requirement :)

> Regards,
>
> Adam

-- 
Regards,
Xiyue Deng

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

#1269586

Control: tags -1 + confirmed

On Fri, 2025-11-07 at 21:52 -0800, Xiyue Deng wrote:
> Control: tags -1 - moreinfo
> 
> Hi Adam,
> 
> "Adam D. Barratt" <adam@adam-barratt.org.uk> writes:
> 
> > Control: tags -1 + moreinfo
> > 
> > On Thu, 2025-11-06 at 17:16 -0800, Xiyue Deng wrote:
> > 
> > > This update fixes bug#1120049 which affects user to invoke some
> > > magit
> > > functions from a dired buffer.
> > 
> > [...]
> > >   [ ] the issue is verified as fixed in unstable
> > > 
> > > Note: this fix is still pending for unstable due to a newer magit
> > > version is awaiting emacs-cond-let to leave the NEW queue.  This
> > > should not block the fix in stable IMHO.
> > 
> > I'm afraid that we do want fixes to have been made to unstable
> > first.
> > Please remove the moreinfo tag once that's happened.
> > 
> 
> Ack.  I have just pushed 4.3.8-2 to unstable which included the fix
> (I was hoping that the NEW queue processing would happen soon, but
> well). I think this should satisfy the requirement :)

Thanks. Please go ahead.

Regards,

Adam

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

#1269606

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

"Adam D. Barratt" <adam@adam-barratt.org.uk> writes:

> Control: tags -1 + confirmed
>
> On Fri, 2025-11-07 at 21:52 -0800, Xiyue Deng wrote:
>> Control: tags -1 - moreinfo
>> 
>> Hi Adam,
>> 
>> "Adam D. Barratt" <adam@adam-barratt.org.uk> writes:
>> 
>> > Control: tags -1 + moreinfo
>> > 
>> > On Thu, 2025-11-06 at 17:16 -0800, Xiyue Deng wrote:
>> > 
>> > > This update fixes bug#1120049 which affects user to invoke some
>> > > magit
>> > > functions from a dired buffer.
>> > 
>> > [...]
>> > >   [ ] the issue is verified as fixed in unstable
>> > > 
>> > > Note: this fix is still pending for unstable due to a newer magit
>> > > version is awaiting emacs-cond-let to leave the NEW queue.  This
>> > > should not block the fix in stable IMHO.
>> > 
>> > I'm afraid that we do want fixes to have been made to unstable
>> > first.
>> > Please remove the moreinfo tag once that's happened.
>> > 
>> 
>> Ack.  I have just pushed 4.3.8-2 to unstable which included the fix
>> (I was hoping that the NEW queue processing would happen soon, but
>> well). I think this should satisfy the requirement :)
>
> Thanks. Please go ahead.
>

Thanks!  Uploaded.

> Regards,
>
> Adam

-- 
Regards,
Xiyue Deng

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

#1269625

On Sat, 2025-11-08 at 20:53 -0800, Xiyue Deng wrote:
> "Adam D. Barratt" <adam@adam-barratt.org.uk> writes:
> > Thanks. Please go ahead.
> > 
> 
> Thanks!  Uploaded.

You included binary packages in your upload, but source-only is much
preferred unless there's a good reason, so that we can make sure the
packages were built in clean environments.

As the package is arch:all, we can't binNMU it. I've therefore marked
the upload for rejection. Please feel free to re-upload as a source-
only build.

Regards,

Adam

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

#1269686

Hi,

On Sun, 2025-11-09 at 10:18 +0000, Adam D. Barratt wrote:
> On Sat, 2025-11-08 at 20:53 -0800, Xiyue Deng wrote:
> > "Adam D. Barratt" <adam@adam-barratt.org.uk> writes:
> > > Thanks. Please go ahead.
> > > 
> > 
> > Thanks!  Uploaded.
> 
> You included binary packages in your upload, but source-only is much
> preferred unless there's a good reason, so that we can make sure the
> packages were built in clean environments.
> 
> As the package is arch:all, we can't binNMU it. I've therefore marked
> the upload for rejection. Please feel free to re-upload as a source-
> only build.

I can see that you've reuploaded, but apparently including binary
packages again:

$ grep "\.deb$" ~/queue/p-u-new/magit_4.3.5-1+deb13u1_amd64.changes
 6b493d3d9405de425bdaba96695cc84e2ac0d0c6 10520 elpa-git-commit_4.3.5-1+deb13u1_all.deb
 3ef4ee25f9bde01da832cff764b899e743f9e1ee 158904 elpa-magit-section_4.3.5-1+deb13u1_all.deb
 bb65b2192f0de45b858b7040df57ac54d42d2b27 1236552 elpa-magit_4.3.5-1+deb13u1_all.deb
 5070bea1d015c064236a91ede4f19b34a4c617181b0fece2450696cc2f58dbd1 10520 elpa-git-commit_4.3.5-1+deb13u1_all.deb
 ffa28fac9587c7bb06ddf4c9e5d5037a2c264f407d4180b82cef8b9f80b12769 158904 elpa-magit-section_4.3.5-1+deb13u1_all.deb
 3187d5d1301d54f638a2d4fbad5f531a4ab7b9c40e82228f070d3c6d5e668c63 1236552 elpa-magit_4.3.5-1+deb13u1_all.deb
 c487df7e793b51a5222abceec04edeba 10520 oldlibs optional elpa-git-commit_4.3.5-1+deb13u1_all.deb
 22511bd321076561030323927dbad29e 158904 editors optional elpa-magit-section_4.3.5-1+deb13u1_all.deb
 a039ed32dc2bdbcc46c5869249887c26 1236552 editors optional elpa-magit_4.3.5-1+deb13u1_all.deb

Regards,

Adam

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

#1269699

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

Hi Xiyue Deng,

On Sun, 09 Nov 2025 23:03:55 -0800 Xiyue Deng <manphiz@gmail.com> wrote:
> Sorry I missed your previous email.  I also got confused that even if I
> tried to build using `sbuild --source-only-change' it still generates a
> *_amd64.changes, and by default it doesn't provide a *_source.buildinfo
> and so debsign fails to sign *_source.changes.  So I signed the other
> *_amd64.changes and uploaded that, which apparently had the same effect.
> 
> So it turns out I can make *_source.buildinfo a symlink to
> *_amd64.buildinfo and it will let debsign pass.  I have now reuploaded
> the *_source.changes which hopefully should be intended.  Sorry for the
> double failure.
> 
> (Also, if there is a way to generate *_source.buildinfo please let me
> know :)

please do not symlink  *_source.buildinfo to *_amd64.buildinfo.

I would be very interested in how you made sbuild create a *_source.buildinfo.
This is out-of-scope for this bug but I'd like to see a reproducer of this
problem and I'd be happy to receive a bug against sbuild for this problem.

None of the 303 *_source.changes files that I have locally as leftovers from previous builds with sbuild --source-only-changes point to a *_source.buildinfo.They should not.

Thanks!

cheers, josch

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

#1269700

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

Hi Johannes,

Johannes Schauer Marin Rodrigues <josch@debian.org> writes:

> Hi Xiyue Deng,
>
> On Sun, 09 Nov 2025 23:03:55 -0800 Xiyue Deng <manphiz@gmail.com> wrote:
>> Sorry I missed your previous email.  I also got confused that even if I
>> tried to build using `sbuild --source-only-change' it still generates a
>> *_amd64.changes, and by default it doesn't provide a *_source.buildinfo
>> and so debsign fails to sign *_source.changes.  So I signed the other
>> *_amd64.changes and uploaded that, which apparently had the same effect.
>> 
>> So it turns out I can make *_source.buildinfo a symlink to
>> *_amd64.buildinfo and it will let debsign pass.  I have now reuploaded
>> the *_source.changes which hopefully should be intended.  Sorry for the
>> double failure.
>> 
>> (Also, if there is a way to generate *_source.buildinfo please let me
>> know :)
>
> please do not symlink  *_source.buildinfo to *_amd64.buildinfo.
>
> I would be very interested in how you made sbuild create a *_source.buildinfo.
> This is out-of-scope for this bug but I'd like to see a reproducer of this
> problem and I'd be happy to receive a bug against sbuild for this problem.
>
> None of the 303 *_source.changes files that I have locally as leftovers from previous builds with sbuild --source-only-changes point to a *_source.buildinfo.They should not.
>

Exactly, it didn't!  Sorry if my previous email was not clear: `sbuild
--source-only-changes' only produces *_amd64.buildinfo.

The issue is that in this case, `debsign'ing *_source.changes fails
because it's looking for *_source.buildinfo but only *_amd64.buildinfo
is available.  So I wonder, how to invoke sbuild so that `debsign'ing
*_source.changes can succeed OOTB?

> Thanks!
>
> cheers, josch



-- 
Regards,
Xiyue Deng

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

#1269702

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

Hi,

Quoting Xiyue Deng (2025-11-10 09:36:05)
> Exactly, it didn't!  Sorry if my previous email was not clear: `sbuild
> --source-only-changes' only produces *_amd64.buildinfo.
> 
> The issue is that in this case, `debsign'ing *_source.changes fails because
> it's looking for *_source.buildinfo but only *_amd64.buildinfo is available.
> So I wonder, how to invoke sbuild so that `debsign'ing *_source.changes can
> succeed OOTB?

debsign should only look for a *_source.buildinfo if that is what your
*_source.changes references. Is that the case?

Thanks!

cheers, josch

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

#1269711

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

Hi Johannes,

Johannes Schauer Marin Rodrigues <josch@debian.org> writes:

> Hi,
>
> Quoting Xiyue Deng (2025-11-10 09:36:05)
>> Exactly, it didn't!  Sorry if my previous email was not clear: `sbuild
>> --source-only-changes' only produces *_amd64.buildinfo.
>> 
>> The issue is that in this case, `debsign'ing *_source.changes fails because
>> it's looking for *_source.buildinfo but only *_amd64.buildinfo is available.
>> So I wonder, how to invoke sbuild so that `debsign'ing *_source.changes can
>> succeed OOTB?
>
> debsign should only look for a *_source.buildinfo if that is what your
> *_source.changes references. Is that the case?
>

That is the case indeed.  See the excerpt below:

,----
| ...
| Checksums-Sha1:
|  d90afa378e58b232fe21992cff1fbc7e42977fbd 2363 magit_4.3.5-1+deb13u1.dsc
|  37eeba95c013f01e38f7ca39c96d1dbc48f1873a 10788 magit_4.3.5-1+deb13u1.debian.tar.xz
|  c18b554404aeca8d4c3fd2a50d414085f3c3674a 11079 magit_4.3.5-1+deb13u1_source.buildinfo
| Checksums-Sha256:
|  be20fc0f824bec554d3d927a8783f7231896f5b7c85848491a23289c8784241a 2363 magit_4.3.5-1+deb13u1.dsc
|  5659e1e66a333489299044b2860b57994a9094fd258b9584a7d754d8d8146957 10788 magit_4.3.5-1+deb13u1.debian.tar.xz
|  9786481e217a4bec28b391d7d4eed5878c3a0b3a4f97c5cfdb23eb182ca5b520 11079 magit_4.3.5-1+deb13u1_source.buildinfo
| Files:
|  175446d13f8a78c2cbb474c3572e56d0 2363 editors optional magit_4.3.5-1+deb13u1.dsc
|  3ef5785c43a8b9718b317ed9cf44af27 10788 editors optional magit_4.3.5-1+deb13u1.debian.tar.xz
|  8c97cea70d25224eb52d2a31f05a3842 11079 editors optional magit_4.3.5-1+deb13u1_source.buildinfo
| ...
`----

And yet, only *_amd64.buildinfo was produced even when I run "sbuild -A
-s --source-only-change" as suggested by the wiki[1].  What would be the
correct way to let sbuild generate *_source.buildinfo?

P.S. after some digging, it turns out that as a dgit user I should have
just run "dgit push-source" which would just DTRT.  Still, it would be
good to know how to do that using sbuild.

> Thanks!
>
> cheers, josch

[1] https://wiki.debian.org/SourceOnlyUpload

-- 
Regards,
Xiyue Deng

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

#1269718

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

Hi,

Quoting Xiyue Deng (2025-11-10 14:07:28)
> And yet, only *_amd64.buildinfo was produced even when I run "sbuild -A -s
> --source-only-change" as suggested by the wiki[1].  What would be the correct
> way to let sbuild generate *_source.buildinfo?

the -s option to sbuild keeps causing problems. This is why in its man page it
is currently documented like this:

> -s, --source
>     Build the source package in addition to the other requested build
>     artifacts. By default, the dsc will not be rewritten because the source
>     package is the input to sbuild, not its output. Even when running from an
>     unpacked source tree sbuild will first build the source package using
>     dpkg-source and then pass that on to the sbuild machinery. Use this option
>     only when you know what you are doing. This will rewrite the original dsc
>     passed to sbuild.

Using the -s option with sbuild is like running "convert foo.jpg bar.png" and
then imagemagick overwrites foo.jpg (the input). Please don't use -s. The
wiki page you are quoting introduced the -s option 7 years ago with this
change:

https://wiki.debian.org/SourceOnlyUpload?action=diff&rev1=12&rev2=13

I corrected that wiki page. Thank you for sharing where you had this from.
Your sbuild command will do the right thing if you just omit the -s option.

Thanks!

cheers, josch

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

#1269766

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

Hi Johannes,

Johannes Schauer Marin Rodrigues <josch@debian.org> writes:

> Hi,
>
> Quoting Xiyue Deng (2025-11-10 14:07:28)
>> And yet, only *_amd64.buildinfo was produced even when I run "sbuild -A -s
>> --source-only-change" as suggested by the wiki[1].  What would be the correct
>> way to let sbuild generate *_source.buildinfo?
>
> the -s option to sbuild keeps causing problems. This is why in its man page it
> is currently documented like this:
>
>> -s, --source
>>     Build the source package in addition to the other requested build
>>     artifacts. By default, the dsc will not be rewritten because the source
>>     package is the input to sbuild, not its output. Even when running from an
>>     unpacked source tree sbuild will first build the source package using
>>     dpkg-source and then pass that on to the sbuild machinery. Use this option
>>     only when you know what you are doing. This will rewrite the original dsc
>>     passed to sbuild.
>
> Using the -s option with sbuild is like running "convert foo.jpg bar.png" and
> then imagemagick overwrites foo.jpg (the input). Please don't use -s. The
> wiki page you are quoting introduced the -s option 7 years ago with this
> change:
>
> https://wiki.debian.org/SourceOnlyUpload?action=diff&rev1=12&rev2=13
>
> I corrected that wiki page. Thank you for sharing where you had this from.
> Your sbuild command will do the right thing if you just omit the -s option.
>
> Thanks!
>
> cheers, josch

Thanks for the tip!  Though unfortunately dropping "-s" didn't seem to
make any difference: it still produces *_amd64.buildinfo only.  I took a
closer look at `man sbuild' and thought that this could be the default
behavior for --arch-all where it will try to build arch:all packages and
hence produced the buildinfo with the host arch (amd64).  I tried to
turn it off but it will cause the build to fail due to the following
error:

,----
| E: dsc: amd64 not in arch list or does not match any arch wildcards: all -- skipping
`----

So I guess that's probably only used for special cases (e.g. buildd)?
Anyway, I guess it's probably easier to just use "dgit push-source" or
tag2upload.

P.S. Do you think it's beneficial to also change the sbuild wiki page[1]
which also turns on --source by suggesting `$build_source = 1;'?

[1] https://wiki.debian.org/sbuild

-- 
Regards,
Xiyue Deng

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

#1269772

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

Hi,

Quoting Xiyue Deng (2025-11-11 02:02:33)
> Thanks for the tip!  Though unfortunately dropping "-s" didn't seem to make
> any difference: it still produces *_amd64.buildinfo only.

yes. That is expected. The buildinfo file describes your binary artifacts which
are produced by sbuild from the source. So the *_source.changes you upload will
reference a *_amd64.buildinfo.

> I took a closer look at `man sbuild' and thought that this could be the
> default behavior for --arch-all where it will try to build arch:all packages
> and hence produced the buildinfo with the host arch (amd64). I tried to turn
> it off but it will cause the build to fail due to the following error:
> 
> ,----
> | E: dsc: amd64 not in arch list or does not match any arch wildcards: all -- skipping
> `----
> 
> So I guess that's probably only used for special cases (e.g. buildd)?

It has other uses as well but is not relevant to your problem which is not a
problem anymore.

> Anyway, I guess it's probably easier to just use "dgit push-source" or
> tag2upload.
> 
> P.S. Do you think it's beneficial to also change the sbuild wiki page[1]
> which also turns on --source by suggesting `$build_source = 1;'?
> 
> [1] https://wiki.debian.org/sbuild

I do not see that page recommending -s or --source. Where does it do that?

You really do *not* want to run sbuild with -s or --source. If you have ideas
on how I could make the documentation more clear about this I'd be happy to
improve it.

So many people add -s to sbuild that I am tempted to remove the option for
good.

Thanks!

cheers, josch

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

#1269784

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

Hi,

Quoting Xiyue Deng (2025-11-11 08:48:24)
> > I do not see that page recommending -s or --source. Where does it do that?
> >
> > You really do *not* want to run sbuild with -s or --source. If you have ideas
> > on how I could make the documentation more clear about this I'd be happy to
> > improve it.
> >
> > So many people add -s to sbuild that I am tempted to remove the option for
> > good.
> >
> 
> The option is named `$build_source' in the example config.  I attempted
> to updated the comment of this part and set its value to 0[1].  Please
> feel free to update it in a more definitive manner.
> 
> [1] https://wiki.debian.org/sbuild?action=diff&rev1=330&rev2=331

thank you! Since a lot of people seem to be reading the wiki page about sbuild
instead of its man page I took the liberty of completely deleting the
`$build_source` (don't give people ideas) and added an extra section at the end
to explicitly advice against the use of -s or --source.

Soren, I put you into CC because you original added the advice of using sbuild
with $build_source=1 here: https://wiki.debian.org/sbuild?action=diff&rev1=288&rev2=289

Thanks!

cheers, josch

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

#1269810

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

Hi,

Quoting Xiyue Deng (2025-11-11 10:02:45)
> Sorry, spoke too soon: the *_source.changes built using --no-source still
> referenced *_source.buildinfo which didn't exist :(

please share your exact sbuild invocation and the contents of your ~/.sbuildrc
or ~/.config/sbuild/config.pl so that I can reproduce your problem.

Thanks!

cheers, josch

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

#1269826

On Tue, 2025-11-11 at 13:53 +0100, Johannes Schauer Marin Rodrigues
wrote:

[...]
> please share your exact sbuild invocation and the contents of your
> ~/.sbuildrc
> or ~/.config/sbuild/config.pl so that I can reproduce your problem.

At the risk of being a party pooper, it feels like this discussion
isn't really relevant to the p-u request any more.

Regards,

Adam

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

#1269855

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

Quoting Adam D. Barratt (2025-11-11 18:07:45)
> On Tue, 2025-11-11 at 13:53 +0100, Johannes Schauer Marin Rodrigues
> wrote:
> 
> [...]
> > please share your exact sbuild invocation and the contents of your
> > ~/.sbuildrc
> > or ~/.config/sbuild/config.pl so that I can reproduce your problem.
> 
> At the risk of being a party pooper, it feels like this discussion isn't
> really relevant to the p-u request any more.

Agreed. Sorry for that.

Xiyue Deng, can you please file a bug against sbuild if there is anything else
to talk about?

Thanks!

cheers, josch

[toc] | [prev] | [standalone]

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

csiph-web