On Thu, Aug 29, 2019 at 11:23:01AM +0100, Ian Jackson wrote:
> Theodore Y. Ts'o writes ("Re: Git Packaging: Native source formats"):
> > Or if we end up moving to dgit for everything, and we don't want to
> > use pristine-tar (which I like, but I realize that's not an opinion
> > shared by everyone
On Fri, Aug 30, 2019 at 12:29:45AM +0200, Thomas Goirand wrote:
>
> Pristine-tar forces you to have multiple branches when you may only need
> a single one. It's also not reliable and may easily generate different
> tarballs for the same tag, which defeats its purpose (and no, the
> workaround to
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.
Total number of orphaned packages: 1350 (new: 1)
Total number of packages offered up for adoption: 159 (new: 1)
Total number of packages reques
On 8/29/19 1:49 AM, Theodore Y. Ts'o wrote:
> Or if we end up moving to dgit for everything, and we don't want to
> use pristine-tar (which I like, but I realize that's not an opinion
> shared by everyone; some people seem to hate it
/me raises hand. I hate it.
Pristine-tar forces you to have mul
Sam Hartman writes:
> Using native source formats (1.0 and 3.0 (native)) is attractive for
> some git workflows. It means you can just export the git repository and
> don't need to make sure that you use the same upstream tarball when
> upstream versions are the same. You don't need to synthesi
On 2019-08-28, Sam Hartman wrote:
> * I've heard at least one person claim that native format packages are
> problematic for downstreams.
> I'd like to better understand both the theoretical argument here and
> to understand from downstreams whether it is an issue in practice.
>
> For down
On 8/29/2019 8:32 PM, Andrej Shadura wrote:
>> So `3.0 (native)' is not strictly better than 1.0. dpkg-source
>> refuses to work in the situation where I am saying (and you seem to be
>> agreeing) that it shouldn't even print a warning ...
>
> I have to disagree with you but I consider this stric
Package: wnpp
Severity: wishlist
Owner: Denis Danilov
* Package name: fortran-language-server
Version : 1.10.2
Upstream Author : Chris Hansen
* URL : https://github.com/hansec/fortran-language-server
* License : MIT
Programming Lang: Python
Description
On Thu, 29 Aug 2019 at 16:25:35 +0100, Ian Jackson wrote:
> Simon McVittie writes ("Re: Git Packaging: Native source formats"):
> > for
> > version 1.0 source packages, detecting a non-native version with a native
> > source format is the only way to generate any sort of warning about this.
>
> Th
Ian Jackson writes ("Re: Git Packaging: Native source formats"):
> Simon McVittie writes ("Re: Git Packaging: Native source formats"):
> > Unlike 1.0 (non-native) vs. 3.0 (quilt), where some people prefer one and
> > some people prefer the other, I am not aware of any advantages of 1.0
> > (native)
Milan Kupcevic writes ("Re: Git Packaging: Native source formats"):
> I've also seen developers deleting a git tag and then creating a new
> git tag using exactly the same name/release number pointing to
> different commit.
It is possible to avoid some of these problems by using a git server
which
Simon McVittie writes ("Re: Git Packaging: Native source formats"):
> On Thu, 29 Aug 2019 at 11:56:55 +0100, Ian Jackson wrote:
> > If you already don't care about bit-identical upstream tarballs, then
> > dealing with these tarballs is a reasonably well-solved problem.
> > git-deborig etc. FTW.
>
Mattia Rizzolo writes ("Re: dput problem: Ancient sha256sum?"):
> That said, the fact that your .orig.tar.gz changed is an indicator
> that you are doing something fishy and you should double check your
> workflow. You should not be able to accidentally end up with a
> different .orig.tar.gz.
I a
On 8/28/19 4:00 PM, Sam Hartman wrote:
>
> Back in the day, one of the big reasons for separating .orig.tar.gz from
> .diff.gz was to reuse upstream tarballs for space reasons, both in terms
> of space on mirrors when the pool had two Debian revisions with the same
> upstream, as well as to reduce
On Thu, 29 Aug 2019 at 11:56:55 +0100, Ian Jackson wrote:
> If you already don't care about bit-identical upstream tarballs, then
> dealing with these tarballs is a reasonably well-solved problem.
> git-deborig etc. FTW.
I think it's important to distinguish between the two things that you
might m
That said, the fact that your .orig.tar.gz changed is an indicator that you
are doing something fishy and you should double check your workflow. You
should not be able to accidentally end up with a different .orig.tar.gz.
On Thu, 29 Aug 2019, 3:18 pm Peter Pentchev, wrote:
> On Thu, Aug 29, 201
On Thu, Aug 29, 2019 at 03:49:57AM +0100, Ben Hutchings wrote:
> On Thu, 2019-08-29 at 00:33 +0200, dettus wrote:
> > So, I am trying to make a package out of my awesome project dMagnetic.
> > I applied some patches, but unfortunately, now I am getting some errors.
> > After each attempt to dput so
Hi,
On Wed, Aug 28, 2019 at 04:00:10PM -0400, Sam Hartman wrote:
> Back in the day, one of the big reasons for separating .orig.tar.gz from
> .diff.gz was to reuse upstream tarballs for space reasons, both in terms
> of space on mirrors when the pool had two Debian revisions with the same
> upstr
Package: wnpp
Severity: wishlist
Owner: Dawid Dziurla
* Package name: gitbatch
Version : 0.5.0-1
Upstream Author : Ibrahim Serdar Acikgoz
* URL : https://github.com/isacikgoz/gitbatch
* License : Expat
Programming Lang: Go
Description : Manage git repos
Sam Hartman writes ("Git Packaging: Native source formats"):
> Internet is faster and disks are cheaper.
> I assert this is much less of a concern than it used to be.
We have some extremely large packages. Also we have users in places
where internet is slow and/or expensive.
Even for medium-size
Theodore Y. Ts'o writes ("Re: Git Packaging: Native source formats"):
> Or if we end up moving to dgit for everything, and we don't want to
> use pristine-tar (which I like, but I realize that's not an opinion
> shared by everyone; some people seem to hate it), and upstream uses a
> non-git repo (s
Holger Levsen writes ("Re: tag2upload service architecture and risk assessment
- draft v2"):
> On Wed, Aug 28, 2019 at 05:07:00PM +0100, Ian Jackson wrote:
> > In my proposal the source package is reproducible (in the
> > "reproducible builds" sense) from the uploader's signed git tag.
>
> i'm
On Wed, Aug 28, 2019 at 05:07:00PM +0100, Ian Jackson wrote:
> In my proposal the source package is reproducible (in the
> "reproducible builds" sense) from the uploader's signed git tag.
i'm confused. 'reproducible builds' is about creating bit by bit
identical binaries from a given source.
i
Joerg Jaspert writes ("Re: tag2upload service architecture and risk assessment
- draft v2"):
> First off: I, for personal reasons, am a bit detached right now with
> anything Debian (though that should change soon). For that reason, I
> haven't read most of the mail threads, though i skimmed over
Package: wnpp
Severity: wishlist
Owner: Nicholas D Steeves
Package name: pyprof2calltree
Version : 1.4.4
Upstream Author : Peter Waller
URL : https://github.com/pwaller/pyprof2calltree
License : Expat, MIT, or custom-permissive (needs verification)
Programming Lan
Hi,
On Wed, 28 Aug 2019, Sam Hartman wrote:
> Internet is faster and disks are cheaper.
I'm not sure that DSA (which is maintaining snapshot.debian.org) will
be happy with this assertion.
> Using native source formats (1.0 and 3.0 (native)) is attractive for
> some git workflows. It means you c
Hi,
I reviewed the whole thread and the point of friction is the requirement
to sign the .dsc file to make sure that the source package matches what
the maintainer intended to upload. Ian doesn't want the maintainer to have
to deal with the .dsc and the ftpmasters wants to have a signature within
27 matches
Mail list logo
