Hello,
On Tue 29 Oct 2019 at 08:32AM +01, Tobias Frost wrote:
>> For example, you would not be able to do this:
>>git clone salsa:something
>>cd something
>>make some straightforward change
>>git tag# } [1]
>>git push # }
>> Instead you would have to download the .origs
Helmut Grohne writes ("Re: Building Debian source packages reproducibly (was:
Re: [RFC] Proposal for new source format)"):
> I think I'd trust the tag2upload service given the documentation you
> presented about it. I'm less faithful in all dgit installations being
>
Hi Didier
On Mon, Oct 28, 2019 at 10:05:11AM +0100, Didier 'OdyX' Raboud wrote:
> Of course, all of this can only work if we can have, or make the ".git to
> .dsc" conversion reproducible; hence my query.
Now, please read the first mail of this thread again. Yes, maybe parts
of it are unclear,
Hi Ian,
On Tue, Oct 29, 2019 at 12:54:57PM +, Ian Jackson wrote:
> I wonder if I have misunderstood you, because:
>
> The tag2upload proposal is based on dgit, which already provides this.
> dgit indeed defines an isomorphism between source packages and git
> trees, and dgit clone gives a git
Helmut Grohne writes ("Re: Building Debian source packages reproducibly (was:
Re: [RFC] Proposal for new source format)"):
> In other words, I want these formats (source package and tagged git
> tree) to be isomorphic (minus history). This requirement is too strong
> sin
On 2019-10-29 08:32, Tobias Frost wrote:
On Mon, Oct 28, 2019 at 05:53:00PM +, Ian Jackson wrote:
(...)
For example, you would not be able to do this:
git clone salsa:something
cd something
make some straightforward change
git tag# } [1]
git push # }
Instead you would
Hi Ian,
On Mon, Oct 28, 2019 at 05:53:00PM +, Ian Jackson wrote:
(...)
> For example, you would not be able to do this:
>git clone salsa:something
>cd something
>make some straightforward change
>git tag# } [1]
>git push # }
> Instead you would have to download the
Hi Ian,
On Mon, Oct 28, 2019 at 05:53:00PM +, Ian Jackson wrote:
> The sticking point, as I understand it, is that this still does not
> allow dak to verify that the *contents* of the .dsc were as intended
> by the uploading human. [0]
>
> In the tag2upload proposal, the conversion from git t
On October 28, 2019 5:53:00 PM UTC, Ian Jackson
wrote:
>Scott Kitterman writes ("Re: Building Debian source packages
>reproducibly (was: Re: [RFC] Proposal for new source format)"):
>> Effectively tag2upload would replace DAK as the entry point for
>> packages into
Scott Kitterman writes ("Re: Building Debian source packages reproducibly (was:
Re: [RFC] Proposal for new source format)"):
> Effectively tag2upload would replace DAK as the entry point for
> packages into the archive (the equivalent to the current source
> package signature
On 2019-10-28 10:05 +0100, Didier 'OdyX' Raboud wrote:
> Le mercredi, 23 octobre 2019, 15.49:11 h CET Theodore Y. Ts'o a écrit :
>> On Wed, Oct 23, 2019 at 11:18:24AM +1000, Russell Stuart wrote:
>> > On Tue, 2019-10-22 at 16:52 -0700, Russ Allbery wrote:
>> > > That seems excessively pessimistic.
On Monday, October 28, 2019 9:45:36 AM EDT Theodore Y. Ts'o wrote:
> On Mon, Oct 28, 2019 at 10:05:11AM +0100, Didier 'OdyX' Raboud wrote:
> > Where I'm coming from is that we were discussing the tag2upload problem at
> > miniDebConf Vaumarcus. The heart of the problem is that FTP-Master are
> > (c
On Mon, Oct 28, 2019 at 10:05:11AM +0100, Didier 'OdyX' Raboud wrote:
> Where I'm coming from is that we were discussing the tag2upload problem at
> miniDebConf Vaumarcus. The heart of the problem is that FTP-Master are
> (currently) not going to accept .dscs built reproducibly by a (even trusted
Hello,
In fact what can be important is problem of downloading artifacts
during build. At least in Java world given application can be small but
be dependant on many libs which are downloaded during build. Program
works, build is reproducible, but we can have no idea what it consist
of.
Best rega
14 matches
Mail list logo
