Hello,
If you look at the djangorestframework git repository, it is failing to
build due to tests failing.
I incorrectly filed a bug report upstream about this:
https://github.com/tomchristie/django-rest-framework/issues/3524
Upstream correctly pointed out that the test class is decorated by the
On Oct 22, 2015, at 08:32 AM, Ben Finney wrote:
>+1
>http://www.slate.com/articles/technology/technology/2011/01/space_invaders.html>
GOML
-Barry
:)
On Wed, Oct 21, 2015 at 11:01 PM, Brian May wrote:
> Maybe we should fix #801666 first and then revisit this question?
git-dpm hasnt seen a single line changed since more than a year
(http://anonscm.debian.org/cgit/git-dpm/git-dpm.git/) so I wont hold
my breath on it :(
--
Sandro Tosi (aka morp
Sandro Tosi writes:
> I dont know if this integrates easily with git-dpm though (from a very
> high level, it seems they have some incompatibilities in particular on
> how git-dpm keep tracks of the upstream source)
Maybe we should fix #801666 first and then revisit this question?
--
Brian May
Piotr Ożarowski writes:
> [Barry Warsaw, 2015-10-21]
> > """
> > DPMT requires a pristine-tar branch, and only upstream tarballs can be used
> > to
> > advance the upstream branch. Complete upstream git history should be
> > avoided
> > in the upstream branch.
> > """
>
> just a tiny change: s
On Wed, Oct 21, 2015 at 3:48 PM, Barry Warsaw wrote:
> On Oct 21, 2015, at 08:36 AM, Sandro Tosi wrote:
>
>>I need to backport quite some packages, and use often experimental to
>>stage big packages new releases (think of numpy and matplotlib) so it
>>is not a rare situation at all and it should b
On 2015-10-21 09:31:04 -0500 (-0500), Ian Cordasco wrote:
> On Wed, Oct 21, 2015 at 8:58 AM, Barry Warsaw wrote:
> > On Oct 21, 2015, at 08:47 PM, Brian May wrote:
> >
> >>in one case this is because upstream have only supplied a *.whl
> >>file on Pypi.
> >
> > I'm *really* hoping that the PyPA wi
On Oct 21, 2015, at 08:36 AM, Sandro Tosi wrote:
>I need to backport quite some packages, and use often experimental to
>stage big packages new releases (think of numpy and matplotlib) so it
>is not a rare situation at all and it should be considered now that we
>are at the beginning of a new era
On Wed, Oct 21, 2015 at 8:58 AM, Barry Warsaw wrote:
> On Oct 21, 2015, at 08:47 PM, Brian May wrote:
>
>>in one case this is because upstream have only supplied a *.whl
>>file on Pypi.
>
> I'm *really* hoping that the PyPA will prohibit binary wheel-only uploads.
I'm not sure why they should pro
[Barry Warsaw, 2015-10-21]
> How about this:
>
> """
> DPMT requires a pristine-tar branch, and only upstream tarballs can be used to
> advance the upstream branch. Complete upstream git history should be avoided
> in the upstream branch.
> """
just a tiny change: s/ / /
--
Piotr Ożarowski
On Oct 21, 2015, at 08:47 PM, Brian May wrote:
>in one case this is because upstream have only supplied a *.whl
>file on Pypi.
I'm *really* hoping that the PyPA will prohibit binary wheel-only uploads.
There is talk about source wheels, and if that happens we'll probably have to
adjust our tools
On Oct 21, 2015, at 09:51 AM, IOhannes m zmölnig (Debian/GNU) wrote:
>i am not a native speaker. so i might get things wrong.
>but i'm not the only non-native English speaker in Debian.
>therefore, i *strongly* suggest that the policy should be written in a
>style that non-natives can understand i
On Oct 21, 2015, at 08:46 AM, Vincent Bernat wrote:
>You should remove the reference to Pypi since tarballs can also be taken
>From GitHub (when upstream doesn't want to ship everything, like tests,
>in Pypi tarballs or doesn't even release tarballs on Pypi):
Yep, done.
-Barry
pgpcjyVfgA4jB.pg
On Oct 21, 2015, at 02:06 PM, Piotr Ożarowski wrote:
>Only version to version upstream changes should be kept in the repository -
>complete upstream git history should be avoided. In order to make it
>easier to cherry-pick upstream commits as patches, add remote repository
>(example below).
>
>
[Barry Warsaw, 2015-10-21]
> What I'm trying to express is the team decision (a couple of debconfs ago) for
> pristine-tars rather than releasing from upstream git. I do want to keep the
> rationale in the policy doc; it's one sentence and it seems to come up often
> enough. Suggestions for bette
Vincent Bernat writes:
> You should remove the reference to Pypi since tarballs can also be taken
> From GitHub (when upstream doesn't want to ship everything, like tests,
> in Pypi tarballs or doesn't even release tarballs on Pypi):
Have filled upstream bugs on issues that prevent me using the
❦ 20 octobre 2015 20:52 -0400, Barry Warsaw :
>>I'd remove this paragraph. Releases can be made via `git archive` and I did
>>that many times (assuming pristine-tar will still keep needed data to
>>regenerate exact same tarball). If you meant that we don't want to keep
>>complete upstream git h
On Tue, 20 Oct 2015, Brian May wrote:
> Barry Warsaw writes:
>
> > Now, in practice, it doesn't matter if you ignore git-dpm and just use quilt
> > *as long as the final state of the repo is compatible with git-dpm*.
> > Meaning,
> > in general, you can make whatever local decisions you want as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2015-10-21 02:17, Ben Finney wrote:
> "IOhannes m zmölnig (Debian/GNU)" writes:
>
>> thanks a lot for preparing all this.
>>
>> On 10/20/2015 10:53 PM, Barry Warsaw wrote:
>>> +DPMT requires upstream tarballs; releases cannot be made from
>>> u
> It does seem like DEP-14 has thought of these complications. My concern is
> that these should be rare so it seems nicer to optimize for the common
> (simple) case and allow for the more complicated branch names when needed.
I need to backport quite some packages, and use often experimental to
20 matches
Mail list logo