On Thu, Apr 11, 2024 at 01:27:54PM -0500, G. Branden Robinson wrote:
> At 2024-04-11T15:37:46+0100, Colin Watson wrote:
> > On Thu, Apr 11, 2024 at 10:26:55AM -0400, Theodore Ts'o wrote:
> > > Or, because some upstream maintainers have learned through, long,
> > > bitter experience that newer versi
At 2024-04-11T15:37:46+0100, Colin Watson wrote:
> On Thu, Apr 11, 2024 at 10:26:55AM -0400, Theodore Ts'o wrote:
> > Or, because some upstream maintainers have learned through, long,
> > bitter experience that newer versions of autoconf tools may result
> > in the generated configure script to be
On Thu, Apr 11, 2024 at 03:37:46PM +0100, Colin Watson wrote:
>
> When was the last time this actually happened to you? I certainly
> remember it being a problem in the early 2.5x days, but it's been well
> over a decade since this actually bit me.
I'd have to go through git archives, but I beli
On Thu, Apr 11, 2024 at 10:26:55AM -0400, Theodore Ts'o wrote:
> On Sat, Apr 06, 2024 at 04:30:44PM +0100, Simon McVittie wrote:
> > But, it is conventional for Autotools projects to ship the generated
> > ./configure script *as well* (for example this is what `make dist`
> > outputs), to allow the
On Sat, Apr 06, 2024 at 04:30:44PM +0100, Simon McVittie wrote:
>
> But, it is conventional for Autotools projects to ship the generated
> ./configure script *as well* (for example this is what `make dist`
> outputs), to allow the project to be compiled on systems that do not
> have the complete A
Hello,
On Sat 06 Apr 2024 at 02:24pm +02, Guillem Jover wrote:
> Hi!
>
> On Sat, 2024-04-06 at 19:13:22 +0800, Sean Whitton wrote:
>> On Fri 05 Apr 2024 at 01:31am +03, Adrian Bunk wrote:
>> > Right now the preferred form of source in Debian is an upstream-signed
>> > release tarball, NOT anythin
Hello,
On Sat 06 Apr 2024 at 02:42pm +03, Adrian Bunk wrote:
> On Sat, Apr 06, 2024 at 07:13:22PM +0800, Sean Whitton wrote:
>> Hello,
>>
>> On Fri 05 Apr 2024 at 01:31am +03, Adrian Bunk wrote:
>>
>> >
>> > Right now the preferred form of source in Debian is an upstream-signed
>> > release tarba
On 2024-04-06 16:30:44 +0100 (+0100), Simon McVittie wrote:
[...]
> Indeed, if upstream does ship generated files in addition to the actual
> source code, we have traditionally said that Debian package maintainers
> "should, except where impossible for legal reasons, preserve the entire
> building
On Sat, 06 Apr 2024 at 15:54:51 +0200, kpcyrd wrote:
> On 4/6/24 1:42 PM, Adrian Bunk wrote:
> > You cannot simply proclaim that some git tree is the preferred form of
> > modification without shipping said git tree in our ftp archive.
> >
> > If your claim was true, then Debian and downstreams wo
On Sat, Apr 06, 2024 at 03:54:51PM +0200, kpcyrd wrote:
>...
> autotools pre-processed source code is clearly not "the preferred form of
> the work for making modifications", which is specifically what I'm saying
> Debian shouldn't consider a "source code input" either, to eliminate this
> vector f
On 4/6/24 1:42 PM, Adrian Bunk wrote:
You cannot simply proclaim that some git tree is the preferred form of
modification without shipping said git tree in our ftp archive.
If your claim was true, then Debian and downstreams would be violating
licences like the GPL by not providing the preferred
Hi!
On Sat, 2024-04-06 at 19:13:22 +0800, Sean Whitton wrote:
> On Fri 05 Apr 2024 at 01:31am +03, Adrian Bunk wrote:
> > Right now the preferred form of source in Debian is an upstream-signed
> > release tarball, NOT anything from git.
>
> The preferred form of modification is not simply up for
On Sat, Apr 06, 2024 at 07:13:22PM +0800, Sean Whitton wrote:
> Hello,
>
> On Fri 05 Apr 2024 at 01:31am +03, Adrian Bunk wrote:
>
> >
> > Right now the preferred form of source in Debian is an upstream-signed
> > release tarball, NOT anything from git.
>
> The preferred form of modification is
Hello,
On Fri 05 Apr 2024 at 01:31am +03, Adrian Bunk wrote:
>
> Right now the preferred form of source in Debian is an upstream-signed
> release tarball, NOT anything from git.
The preferred form of modification is not simply up for proclamation.
Our practices, which are focused around git, mak
On Fri, Apr 05, 2024 at 01:30:51AM +0200, kpcyrd wrote:
> On 4/5/24 12:31 AM, Adrian Bunk wrote:
> > Hashes of "git archive" tarballs are anyway not stable,
> > so whatever a maintainer generates is not worse than what is on Github.
> >
> > Any proper tooling would have to verify that the contents
On 4/5/24 12:31 AM, Adrian Bunk wrote:
Hashes of "git archive" tarballs are anyway not stable,
so whatever a maintainer generates is not worse than what is on Github.
Any proper tooling would have to verify that the contents is equal.
...
Being able to disregard the compression layer is still
On Fri, Apr 05, 2024 at 01:31:25AM +0300, Adrian Bunk wrote:
> On Thu, Apr 04, 2024 at 09:39:51PM +0200, kpcyrd wrote:
> >...
> > I've checked both, upstreams github release page and their website[1], but
> > couldn't find any mention of .tar.xz, so I think my claim of Debian doing
> > the compress
On Thu, Apr 04, 2024 at 09:39:51PM +0200, kpcyrd wrote:
>...
> I've checked both, upstreams github release page and their website[1], but
> couldn't find any mention of .tar.xz, so I think my claim of Debian doing
> the compression is fair.
>
> [1]: https://www.vim.org/download.php
>...
Perhaps t
On 2024-04-04 21:39:51 +0200 (+0200), kpcyrd wrote:
[...]
> I don't know if Debian has this kind of provenance information available, to
> my knowledge, Debian operates on "our maintainers upload .tar.xz files into
> our archive and we take them for face value". Which does make sense,
> considering
On 4/3/24 4:21 AM, Adrian Bunk wrote:
On Wed, Apr 03, 2024 at 02:31:11AM +0200, kpcyrd wrote:
...
I figured out a somewhat straight-forward way to check if a given `git
archive` output is cryptographically claimed to be the source input of a
given binary package in either Arch Linux or Debian (o
On Wed, Apr 03, 2024 at 02:31:11AM +0200, kpcyrd wrote:
>...
> I figured out a somewhat straight-forward way to check if a given `git
> archive` output is cryptographically claimed to be the source input of a
> given binary package in either Arch Linux or Debian (or both).
For Debian the proper ap
Hello,
I'm going to keep this short, I've been writing a lot of text recently
(which is quite exhausting, on top of my dayjob and all the code I wrote
today afterwards. Apologies if you're still waiting for a reply in one
of the other threads).
I figured out a somewhat straight-forward way t
22 matches
Mail list logo
