Hello,
On Wed 04 Sep 2019 at 08:34AM +02, Johannes Schauer wrote:
> okay now I'm confused. I read [1] and it made me understand that users somehow
> have to remember this horribly complicated sbuild command in certain
> circumstances.
>
> [1]
Johannes Schauer writes ("Re: Bug#868527: [buildd-tools-devel] Bug#868527:
Bug#868527: want sbuild --no-source or something"):
> I just had another idea. Since the issue at hand is, that you need a
> way to transfer the source tree into sbuild and sbuild currently
> only suppo
Hi,
Quoting Sean Whitton (2019-09-02 20:15:23)
> On Mon 02 Sep 2019 at 01:48PM +02, Johannes Schauer wrote:
> > I just had another idea. Since the issue at hand is, that you need a way to
> > transfer the source tree into sbuild and sbuild currently only supports
> > source packages, why can dgit
Hello,
On Mon 02 Sep 2019 at 01:48PM +02, Johannes Schauer wrote:
> I just had another idea. Since the issue at hand is, that you need a way to
> transfer the source tree into sbuild and sbuild currently only supports source
> packages, why can dgit not be amended to build a temporary source
Hi,
Quoting Sean Whitton (2019-09-02 01:00:12)
> > It has been more than two years since the last message in this bugreport.
> > As dgit becomes more and more mature, maybe we should revisit what sbuild
> > could do to improve on the current situation?
> >
> > For example I would not be opposed
Hello Johannes,
On Sat 31 Aug 2019 at 12:55PM +02, Johannes Schauer wrote:
> It has been more than two years since the last message in this bugreport. As
> dgit becomes more and more mature, maybe we should revisit what sbuild could
> do
> to improve on the current situation?
>
> For example I
Hi,
On Mon, 17 Jul 2017 13:18:54 +0100 Ian Jackson
wrote:
> Raphael Hertzog writes ("Re: [buildd-tools-devel] Bug#868527: Bug#868527:
> want sbuild --no-source or something"):
> > On Sun, 16 Jul 2017, Johannes Schauer wrote:
> > > Indeed, the task to solv
Raphael Hertzog writes ("Re: [buildd-tools-devel] Bug#868527: Bug#868527: want
sbuild --no-source or something"):
> On Sun, 16 Jul 2017, Johannes Schauer wrote:
> > Indeed, the task to solve is how to transfer the source into the chroot.
> >
> > But is $(dpkg-sou
Johannes Schauer writes ("Re: [buildd-tools-devel] Bug#868527: want sbuild
--no-source or something"):
> Quoting Ian Jackson (2017-07-17 11:31:07)
> > 4. Building and unpacking a git bundle is pointless work when we know that
> >the destination completely trusts the
Quoting Ian Jackson (2017-07-17 11:31:07)
> That would be a perfectly fine answer from my point of view. However,
> it has a few different behaviours. I'm not sure what is best.
>
> Things I thought of:
>
> 1. If there are files which are ignored, or uncommitted, this would
>use the
Johannes Schauer writes ("Re: [buildd-tools-devel] Bug#868527: want sbuild
--no-source or something"):
> Indeed, the task to solve is how to transfer the source into the chroot.
>
> But is $(dpkg-source -Zgzip -z0 --format=1.0 -sn) really the right
> thing to do? Would
Hi,
On Sun, 16 Jul 2017, Johannes Schauer wrote:
> Indeed, the task to solve is how to transfer the source into the chroot.
>
> But is $(dpkg-source -Zgzip -z0 --format=1.0 -sn) really the right thing to
> do?
No, it's clearly a hack and one that might have side effects due to
differences (for
Quoting Ian Jackson (2017-07-16 14:32:17)
> It would be nice if it were easier to use sbuild with a gitish
> downstream workflow which does not produce "3.0 (quilt)" source
> packages.
>
> [snip]
>
> The above attempt will probably fail.
>
> This is because the package "foo" is probably "3.0
Package: sbuild
Version: 0.73.0-4
Severity: wishlist
It would be nice if it were easier to use sbuild with a gitish
downstream workflow which does not produce "3.0 (quilt)" source
packages.
For example, consider this scenario:
dgit clone foo stretch
cd foo
hack hack hack
git commit
14 matches
Mail list logo
