On Fri, Dec 7, 2018 at 7:48 PM Enrico Weigelt wrote:
> Have there been any cases where those files have been in the
> upstream VCS ? I don't recall any such case.
I assume most of the rejects from NEW would have this issue.
> For the case where certain parts shouldn't be built/shipped due to
> p
On 2018-12-07 12:48 +0100, Enrico Weigelt, metux IT consult wrote:
> On 21.11.18 04:22, Paul Wise wrote:
>
> Actually, since about a decade, I'm not doing any code changes outside
> git, and I'm building packages only directly from git. Frankly, I don't
> see any reason why that can't be the stand
On 21.11.18 04:22, Paul Wise wrote:
> I don't think Andreas was talking about applying the DFSG but about
> files we don't have permission to distribute at all.
Have there been any cases where those files have been in the
upstream VCS ? I don't recall any such case.
For the case where certain pa
On Tue, Nov 20, 2018 at 6:50 PM Jonathan Dowland wrote:
> It was widely done on alioth (by pulling in upstream branches to git
> repos) and I imagine is common on Salsa, too. In practise we are not
> applying the DFSG to the content of the VCS, the wiki, or really much
> except the archive.
I don
On Mon, Nov 19, 2018 at 08:17:03PM +0100, Andreas Metzler wrote:
the main reason for having +dfsg versions is that non-distributable
stuff is removed. Distributing these files in a Debian hosted GIT
repository would not be workable, would it?
It was widely done on alioth (by pulling in upstream
Enrico Weigelt, metux IT consult wrote:
> I'm often seeing packagers directly putting dfsg'ed trees into their git
> repos, w/o any indication how the tree was actually created from the
> original releases.
[...]
> My preferred way (except for rare cases where upstream history is
> extremely huge
On 19.11.18 17:36, Ian Jackson wrote:
Hi,
> I am saying that for packages whose Debian maintainer follow those>
> recommendations, much of what you want would be straightforward - or,>
anyway a lot easier. So I was plugging my recommendations.
Unfortunately, those packages I'm coping w/ don't r
Enrico Weigelt, metux IT consult writes ("Re: git vs dfsg tarballs"):
> On 19.11.18 13:52, Ian Jackson wrote:
> > I think that most of the workflows recommended in these manpages
> >
> >
> > https://manpages.debian.org/stretch-backports/dgit/dgit
On 19.11.18 13:52, Ian Jackson wrote:
> Clearly the transformation on the *tree* can't be reversible because
> in the usual case it is deleting things. So you'll need the history.
It certain can be, if you know the exact orig commit.
Maybe I wasn't really clear here: I wanna do a fully automatic
Enrico Weigelt, metux IT consult writes ("git vs dfsg tarballs"):
> Can we agree on some auomatically reproducable (and inversable)
> transformation process from orig to dfsg tree
Clearly the transformation on the *tree* can't be reversible because
in the usual case it is
Hi folks,
I'm often seeing packagers directly putting dfsg'ed trees into their git
repos, w/o any indication how the tree was actually created from the
original releases.
As I'm doing all patching exclusively via git (no text-based patches
anymore - adding my changes ontop the upstream release t
11 matches
Mail list logo
