sage-fix-pkg-checksums

[John Cremona]

[Re trac #15556]

The command ./sage -sh sage-fix-pkg-checksums is ignoring two files I
put in ./upstream/ called
upstream/database_stein_watkins-20030423.p1.tar.bz2
and
upstream/database_stein_watkins_mini-20030423.p1.tar.bz2

but I cannot see why. When I had two similar files called
upstream/database_stein_watkins-20131220.tar.bz2
and
upstream/database_stein_watkins_mini-20131220.tar.bz2
it worked. By "ignoring" I mean that a list of spkg names goes past
but skips these two, and the relevant checksums.ini files are not
changed. I also tried deleting the old checksums.ini files manually
first, but new ones are not created.

I'm sure that this is something trivial, so please help!

My branch is based off 6.1.beta0 (commit
3735dfdfbbf597e8aaa3376969f064fcd15eeb5f).

John

[John Palmieri]

Does the file package-version.txt have the correct (i.e., matching) version?

  John

[John Cremona]

I think so, e.g. filename is
database_stein_watkins_mini-20030423.p1.tar.bz2
and the file
build/pkgs/database_stein_watkins_mini/package-version.txt
contains
20030423.p1

John

>
> John
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-git" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-git+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Volker Braun]

The tarball name for version 20030423.p1 would be

database_stein_watkins-20030423.tar.bz2

(without the p1) since it is supposed to be the upstream release. The .p1 just means that *sage* patches it. The whole point of the new build system is that we do modify the upstream tarball to fix bugs, we keep our patches separate from it.

[John Cremona]

On 23 December 2013 17:02, Volker Braun <vbrau...@gmail.com> wrote:
> The tarball name for version 20030423.p1 would be
>
> database_stein_watkins-20030423.tar.bz2
>
> (without the p1) since it is supposed to be the upstream release. The .p1
> just means that *sage* patches it. The whole point of the new build system
> is that we do modify the upstream tarball to fix bugs, we keep our patches
> separate from it.

Of course, thanks. So obvious when you have it explained. In fact
the p1 signifies not that the spkg itself (which is just data) has
been changed at all, only that this is a new version of the packaging.

Just my luck that I have been learning these ropes with a couple of
spkgs of which one is 2.7gb....

John

>
>
>
> On Monday, December 23, 2013 3:39:52 PM UTC, John Cremona wrote:
>>
>> [Re trac #15556]
>>
>> The command ./sage -sh sage-fix-pkg-checksums is ignoring two files I
>> put in ./upstream/ called
>> upstream/database_stein_watkins-20030423.p1.tar.bz2
>> and
>> upstream/database_stein_watkins_mini-20030423.p1.tar.bz2
>>
>> but I cannot see why. When I had two similar files called
>> upstream/database_stein_watkins-20131220.tar.bz2
>> and
>> upstream/database_stein_watkins_mini-20131220.tar.bz2
>> it worked. By "ignoring" I mean that a list of spkg names goes past
>> but skips these two, and the relevant checksums.ini files are not
>> changed. I also tried deleting the old checksums.ini files manually
>> first, but new ones are not created.
>>
>> I'm sure that this is something trivial, so please help!
>>
>> My branch is based off 6.1.beta0 (commit
>> 3735dfdfbbf597e8aaa3376969f064fcd15eeb5f).
>>
>> John
>

[John Cremona]

Forgive me returning to this theme:

I have put a new file into ./upstream/ called eclib-2014-01-26.tar.bz2
and changed ./build/pkgs/eclib/package-version.txt so that it contains
2014-01-26
but now running
./sage -sh sage-fix-pkg-checksums
ignores eclib completely (and does not change ./build/pkgs/eclib/checksums.ini .

What have I done wrong?

John

PS Is the sage-git list now deprecated?

[Volker Braun]

I think we don't allow dashes in version numbers, only numbers and dots. It might be version 01-26 of eclib-2014 etc...

Just use eclib-20140126.tar.bz2

[John Cremona]

Thanks for the quick reply!

On 26 January 2014 17:02, Volker Braun <vbrau...@gmail.com> wrote:
> I think we don't allow dashes in version numbers, only numbers and dots. It
> might be version 01-26 of eclib-2014 etc...
>
> Just use eclib-20140126.tar.bz2
>

OK, I will try that. The tarball is made using "make dist" in my
eclib development directory where I changed the version in
configure.ac to 2014-01-26 which was the same format as previous
versions. But of course I can rename the tarball (and re-compress it
using bzip2). I'll try that...and it works! Thanks again,

John

[Jean-Pierre Flori]

On Sunday, January 26, 2014 6:12:38 PM UTC+1, John Cremona wrote:

Thanks for the quick reply!

On 26 January 2014 17:02, Volker Braun <vbrau...@gmail.com> wrote:
> I think we don't allow dashes in version numbers, only numbers and dots. It
> might be version 01-26 of eclib-2014 etc...
>

Yes, it seems dashes break our scripts.
We have the smae problem with singular whose upstream version numbering is 3-1-6 rather than the usual 3.1.6

[John Cremona]

Luckily in this case I can easily change the convention for eclib's
version numbering!

A more complicated version of our scripts should surely be able to
handle this given that we have a whole file dedicated to the text of
the package version?

[Jean-Pierre Flori]

On Tuesday, January 28, 2014 10:10:40 AM UTC+1, John Cremona wrote:

On 27 January 2014 20:55, Jean-Pierre Flori <jpf...@gmail.com> wrote:
>
>
> On Sunday, January 26, 2014 6:12:38 PM UTC+1, John Cremona wrote:
>>
>> Thanks for the quick reply!
>>
>> On 26 January 2014 17:02, Volker Braun <vbrau...@gmail.com> wrote:
>> > I think we don't allow dashes in version numbers, only numbers and dots.
>> > It
>> > might be version 01-26 of eclib-2014 etc...
>> >
>
> Yes, it seems dashes break our scripts.
> We have the smae problem with singular whose upstream version numbering is
> 3-1-6 rather than the usual 3.1.6

Luckily in this case I can easily change the convention for eclib's
version numbering!

A more complicated version of our scripts should surely be able to
handle this given that we have a whole file dedicated to the text of
the package version?

Sure.
IIRC the regexp currently used to split out the package name from the package version looks for the last dash.
Maybe the first dash followed by a number would be more sensible.
But of course someone could always craft a package name which will defeat the regexp...

[John Cremona]

I was thinking that the package-version.txt could be used to define
exactly what string to but between the package name (e.g. eclib) and
suffix (e.g. .tar.gz or .tar .bz2) to determine the current upstream
tarball filename. If there is a patch level that could be defined
seprately, say on a second line in the same file or in a second file
called patch-level.txt (default none if the file does not exist).

[Jean-Pierre Flori]

Oh sure!
That's much smarter...
The dash problem is indeed an artifact of the way we used to deal with spkg tarballs...
We now have the package name as the directory name and the version number within the txt file.
I don't have a strong opinion about splitting the patch level into a different txt file.