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
2505dbc Updated Sage version to 7.1.beta1
a62f35e Trac #19973: More trouble with immutable graphs
993cf5a Trac #19966:
Did this get kicked out to the mirrors?
Nine hours on, and no luck at MIT nor Simon Fraser. But perhaps I'm just
impatient.
Rob
On 01/28/2016 12:42 PM, Volker Braun wrote:
As always, you can get the latest beta version from the "develop" git branch.
Alternatively, the self-contained source t
On Friday, 29 January 2016 05:13:03 UTC, Rob Beezer wrote:
>
> Did this get kicked out to the mirrors?
>
> Nine hours on, and no luck at MIT nor Simon Fraser. But perhaps I'm just
> impatient.
>
at least here it has arrived:
http://www.mirrorservice.org/sites/www.sagemath.org/devel/index.html
cliquer-1.21.p3
Setting up build directory for cliquer-1.21.p3
Finished set up
[...]
Applying patches...
Configuring...
./spkg-install: lin
This problem was caused by running sage-fix-pkg-checksums on 7.1.beta0
with a newer version of cliquer in upstream/
So, it's perhaps not really a bug but it's annoying that there are 2
cliquer tarballs in upstream/ with the same version number. I think the
version number of cliquer should have
Really its a bug in the sage-fix-pkg-checksums scripts; It just randomly
mucks around with filenames and it fails here. The files
cliquer-1.21.tar.gz and cliquer-1.21.tar.bz2 can be distinguished and there
is no reason for why we don't.
On Friday, January 29, 2016 at 5:39:02 PM UTC+1, Jeroen D
Volker Braun wrote:
> Really its a bug in the sage-fix-pkg-checksums scripts; It just randomly
> mucks around with filenames and it fails here. The files
> cliquer-1.21.tar.gz and cliquer-1.21.tar.bz2 can be distinguished and
> there is no reason for why we don't.
If the tarballs' basenames match,
On Saturday, January 30, 2016 at 2:24:43 AM UTC+1, leif wrote:
>
> If the tarballs' basenames match, the (relevant parts of their) contents
> should be identical. IMHO.
>
But the correct function of our tooling should not rely on whether or not
we use that social convention. We define a clear
On Friday, 29 January 2016 16:39:02 UTC, Jeroen Demeyer wrote:
>
> This problem was caused by running sage-fix-pkg-checksums on 7.1.beta0
> with a newer version of cliquer in upstream/
>
> So, it's perhaps not really a bug but it's annoying that there are 2
> cliquer tarballs in upstream/ with
On 2016-01-30 02:03, Volker Braun wrote:
Really its a bug in the sage-fix-pkg-checksums scripts; It just randomly
mucks around with filenames and it fails here. The files
cliquer-1.21.tar.gz and cliquer-1.21.tar.bz2 can be distinguished
How should sage-fix-pkg-checksums then figure out what the
On 2016-01-30 06:34, Dima Pasechnik wrote:
I did not want to increase the version, as it would mean to indicate a
newer version of cliquer, and it's arguably the same, as far as the
functionality goes.
You could have called it dimacliquer-1.21 or something...
--
You received this message becau
>> I did not want to increase the version, as it would mean to indicate a
>> newer version of cliquer, and it's arguably the same, as far as the
>> functionality goes.
>
> You could have called it dimacliquer-1.21 or something...
I think that' s what the .p1, .p2, .p are useful for. So
that the na
On 2016-01-30 10:32, Nathann Cohen wrote:
I think that' s what the .p1, .p2, .p are useful for.
No. The .p1... is for adding patches or changing spkg-install with the
*same* tarball.
--
You received this message because you are subscribed to the Google Groups
"sage-release" group.
To unsubscr
On Saturday, January 30, 2016 at 9:28:06 AM UTC+1, Jeroen Demeyer wrote:
>
> How should sage-fix-pkg-checksums then figure out what the right tarball
> is? I see no other way than just guessing...
>
The mapping package <-> tarball is uniquely determined by checksums.ini and
package_version.txt,
On 01/30/2016 05:31 AM, Jeroen Demeyer wrote:
> On 2016-01-30 10:32, Nathann Cohen wrote:
>> I think that' s what the .p1, .p2, .p are useful for.
> No. The .p1... is for adding patches or changing spkg-install with the
> *same* tarball.
>
The "patch level" or "revision" suffix that all package
This is now fixed in http://trac.sagemath.org/ticket/19984 (needs review)
--
You received this message because you are subscribed to the Google Groups
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-release+unsubscr...@googlegroups.c
On 2016-01-30 11:45, Volker Braun wrote:
The mapping package <-> tarball is uniquely determined by checksums.ini
and package_version.txt, no guessing required.
But the checksums.ini file is *generated* by sage-fix-pkg-checksums. So
this cannot really work.
--
You received this message becaus
On Sunday, January 31, 2016 at 10:16:23 AM UTC+1, Jeroen Demeyer wrote:
>
> But the checksums.ini file is *generated* by sage-fix-pkg-checksums. So
> this cannot really work.
>
If anything, that is a bug in sage-fix-pkg-checksums that it does things
besides fixing checksums. It only works somet
18 matches
Mail list logo
