> On May 15, 2018, at 17:07 , Dima Pasechnik wrote:
>
>
>
> On Tuesday, May 15, 2018 at 9:34:55 PM UTC+1, Justin C. Walker wrote:
>
> > On May 9, 2018, at 11:44 , Volker Braun wrote:
> >
> > As always, you can get the latest beta version from the
On Tuesday, May 15, 2018 at 9:34:55 PM UTC+1, Justin C. Walker wrote:
>
>
> > On May 9, 2018, at 11:44 , Volker Braun > wrote:
> >
> > As always, you can get the latest beta version from the "develop" git
> branch. Alternatively, the self-contained source tarball is at
Under macOS 10.10.5, after downloading the cysignals patch
https://github.com/sagemath/cysignals
/commit/daef81e2fc111378ccc58b3f572eb18c70753a30.patch
into
build/pkgs/cysignals/patches
both the build+docbuild of Python2-based Sage
and the build+nodocbuild of Python3-based Sage
were
> On May 14, 2018, at 11:10 , Volker Braun wrote:
>
> As always, you can get the latest beta version from the "develop" git branch.
> Alternatively, the self-contained source tarball is at
> http://www.sagemath.org/download-latest.html
Built from a fresh clone/update
> On May 9, 2018, at 11:44 , Volker Braun wrote:
>
> As always, you can get the latest beta version from the "develop" git branch.
> Alternatively, the self-contained source tarball is at
> http://www.sagemath.org/download-latest.html
Built from a fresh clone/update of
On Ubuntu 16.04, the command `./sage -t -p --all --long
--optional=sage,optional,external` finishes with:
--
sage -t --long src/sage/coding/code_constructions.py # 1 doctest failed
2018-05-15 18:59 GMT+02:00 Volker Braun :
>
> If you want better merge conflict information: extend the
> "git releasemgr merge " script (part of the
> git-trac repo) to diagnose which ticket the conflict came
> from. Then I'll be happy to include that info when setting
>
If you want better merge conflict information: extend the "git releasemgr
merge " script (part of the git-trac repo) to diagnose which
ticket the conflict came from. Then I'll be happy to include that info when
setting the ticket back...
--
You received this message because you are subscribed
this is already fixed in https://trac.sagemath.org/ticket/25323
please review :-)
On Tuesday, May 15, 2018 at 4:44:03 PM UTC+1, John H Palmieri wrote:
>
> For me on OS X, I get the same failures as in earlier versions (which may
> be related somehow to my system). But if I then do "sage -i
On Tuesday, May 15, 2018 at 4:44:03 PM UTC+1, John H Palmieri wrote:
>
> For me on OS X, I get the same failures as in earlier versions (which may
> be related somehow to my system). But if I then do "sage -i database_gap"
> and run tests again, I get failures in permgroup.py and
For me on OS X, I get the same failures as in earlier versions (which may
be related somehow to my system). But if I then do "sage -i database_gap"
and run tests again, I get failures in permgroup.py and features/gap.py.
For example:
sage -t --long src/sage/features/gap.py
More helpful would be the info which trac tickets in the integration branch
cause these merge failures.
While basing off the branch might be a no-no, adding some positively
reviewed tickets as dependencies to a ticket does not break stuff, at least
in my experience.
I can discover these
The integration branch is going to have its history rewritten regularly.
The issue is that unsuspecting developers might *base* their contribution
on the integration branch (i.e. go to github and select the branch with the
most recent commits), and then have it yanked out from under their feet
Thanks for the release.
On Ubuntu 14.04 I get LOTS of test timeouts that I didn't get
previously. It's possible though that the system is just uder heavy
load, but even re-running the tests with --failed keeps giving me
timeouts for some modules. So I'm concerned about a real performance
On Tue, May 15, 2018 at 3:11 PM, Jeroen Demeyer wrote:
> On 2018-05-15 14:35, Erik Bray wrote:
>>
>> I'm not convinced that's a real problem. This is what I meant by "yes
>> its contents may change and shift rapidly, but for a sophisticated
>> developer who just wants to peek
On 2018-05-15 15:40, Emmanuel Charpentier wrote:
Therefore, I think that contributing to Sage should not *require* a
sophisticated understanding of the finer points of git care and feeding...
Of course not. I don't think that anybody here proposed that.
--
You received this message because
May I argue that we should aim at being able to use *UN*sophisticated
developers (such as, well... myself) ?
There is a *lot* of "maintenance" tasks in Sage that can use (relatively)
ignorant people. For example, maintaining Sage ports of well-understood
packages (such as Maxima or, in my
On 2018-05-15 14:35, Erik Bray wrote:
I'm not convinced that's a real problem. This is what I meant by "yes
its contents may change and shift rapidly, but for a sophisticated
developer who just wants to peek in on the release process this is not
a problem".
I agree that it's not a problem for
FWIW : on Debian testing running on Core i7 + 16 GB RAM, same results as
for 8.3.beta0, i. e. one transient and two permanent errors (the same as
before) :
--
sage -t --long src/sage/rings/padics/padic_lattice_element.py #
On Sat, May 12, 2018 at 10:31 AM, Marc Mezzarobba wrote:
> Jeroen Demeyer wrote:
>> To be honest, I think it's not very meaningful to do that without
>> consulting the release manager. I mean, you can write up all the
>> documentation that you want; in the end, it's the
20 matches
Mail list logo