Re: New packages: unison2.51+4.04.2, unison2.51+4.10.0

2021-12-22 Thread Jon Turney

On 22/12/2021 19:50, Andrew Schulman via Cygwin-apps wrote:

Since I marked unison2.51+4.04.2 as obsoletes: unison2.51, it seems that
unison2.51 now needs to be removed as a separate package? calm says:

ERROR: package 'unison2.51' is at paths unison2.51 and
unison2.51+4.10.0/unison2.51


this says that unison2.51+4.10.0 obsolets unison2.51
not unison2.51+4.04.

Can you confirm ?


Sorry for the confusion. I posted the wrong error message.

Since unison2.51 can only appear in one place, it should be obsoleted by
unison2.51+4.04.2, which uses the same OCaml version.


Yes, note that only one of unison2.51+4.04.2 and unison2.51+4.04.2 can 
obsolete unison2.51.



So Jon, can you please move unison2.51 under unison2.51+4.04.2 ?


Done.


Re: New packages: unison2.51+4.04.2, unison2.51+4.10.0

2021-12-22 Thread Andrew Schulman via Cygwin-apps
> > Since I marked unison2.51+4.04.2 as obsoletes: unison2.51, it seems that
> > unison2.51 now needs to be removed as a separate package? calm says:
> > 
> > ERROR: package 'unison2.51' is at paths unison2.51 and
> > unison2.51+4.10.0/unison2.51
> 
> this says that unison2.51+4.10.0 obsolets unison2.51
> not unison2.51+4.04.
> 
> Can you confirm ?

Sorry for the confusion. I posted the wrong error message.

Since unison2.51 can only appear in one place, it should be obsoleted by
unison2.51+4.04.2, which uses the same OCaml version.

So Jon, can you please move unison2.51 under unison2.51+4.04.2 ?
 
> > Can you help with that?
> 
> my usual solution is
> 
> create directory unison2.51+4.10.0
> move directory unison2.51 under unison2.51+4.10.0
> 
> this will allow the upload.

I did that, but I still got the error message, I think when calm tried to
move my upload into the main file location.

Andrew



Re: New packages: unison2.51+4.04.2, unison2.51+4.10.0

2021-12-22 Thread Marco Atzeri

On 22.12.2021 19:51, Andrew Schulman via Cygwin-apps wrote:

On 22.12.2021 17:21, Andrew Schulman via Cygwin-apps wrote:

Please add me as maintainer of two new unison packages:

unison2.51+4.04.2
unison2.51+4.10.0

These will obsolete the current unison2.51 package.

Thanks, Andrew



added.


Since I marked unison2.51+4.04.2 as obsoletes: unison2.51, it seems that
unison2.51 now needs to be removed as a separate package? calm says:

ERROR: package 'unison2.51' is at paths unison2.51 and
unison2.51+4.10.0/unison2.51


this says that unison2.51+4.10.0 obsolets unison2.51
not unison2.51+4.04.

Can you confirm ?


Can you help with that?


my usual solution is

create directory unison2.51+4.10.0
move directory unison2.51 under unison2.51+4.10.0

this will allow the upload.
Eventually we need to wait 4 hours for "calm" to  perform a full index 
rebuild.






Re: New packages: unison2.51+4.04.2, unison2.51+4.10.0

2021-12-22 Thread Jon Turney

On 22/12/2021 18:51, Andrew Schulman via Cygwin-apps wrote:

On 22.12.2021 17:21, Andrew Schulman via Cygwin-apps wrote:

Please add me as maintainer of two new unison packages:

unison2.51+4.04.2
unison2.51+4.10.0

These will obsolete the current unison2.51 package.

Thanks, Andrew



added.


Since I marked unison2.51+4.04.2 as obsoletes: unison2.51, it seems that
unison2.51 now needs to be removed as a separate package? calm says:


Yeah, this is an unfortunate side-effect of the way upload authorization 
works at the moment.



ERROR: package 'unison2.51' is at paths unison2.51 and
unison2.51+4.10.0/unison2.51

Can you help with that?


I've moved the existing unison2.51 packages to 
unison2.51+4.10.0/unison2.51, which should allow this upload to succeed.


Please try again, and apologies for the inconvenience.



Re: New packages: unison2.51+4.04.2, unison2.51+4.10.0

2021-12-22 Thread Andrew Schulman via Cygwin-apps
> On 22.12.2021 17:21, Andrew Schulman via Cygwin-apps wrote:
> > Please add me as maintainer of two new unison packages:
> > 
> > unison2.51+4.04.2
> > unison2.51+4.10.0
> > 
> > These will obsolete the current unison2.51 package.
> > 
> > Thanks, Andrew
> > 
> 
> added.

Since I marked unison2.51+4.04.2 as obsoletes: unison2.51, it seems that
unison2.51 now needs to be removed as a separate package? calm says:

ERROR: package 'unison2.51' is at paths unison2.51 and
unison2.51+4.10.0/unison2.51

Can you help with that?

Thanks, Andrew



Re: New packages: unison2.51+4.04.2, unison2.51+4.10.0

2021-12-22 Thread Andrew Schulman via Cygwin-apps
> On 22.12.2021 17:21, Andrew Schulman via Cygwin-apps wrote:
> > Please add me as maintainer of two new unison packages:
> > 
> > unison2.51+4.04.2
> > unison2.51+4.10.0
> > 
> > These will obsolete the current unison2.51 package.
> > 
> > Thanks, Andrew
> > 
> 
> added.

Thanks.

> Question: why Unison need all these versions ?
> 
> $ grep "unison" cygwin-pkg-maint
> unison2.27   Andrew Schulman
> unison2.32   Andrew Schulman
> unison2.40   Andrew Schulman
> unison2.45   Andrew Schulman
> unison2.48   Andrew Schulman
> unison2.48+4.04.2Andrew Schulman
> unison2.48+4.08.1Andrew Schulman
> unison2.49   Andrew Schulman
> unison2.51   Andrew Schulman
> unison2.51+4.04.2Andrew Schulman
> unison2.51+4.10.0Andrew Schulman

Yeah. It's too complicated. The problem is that different versions of
unison are only compatible with each other if the first two numbers of the
Unison version are the same, AND they were compiled with compatible
versions of OCaml. 

The underlying problem is that both Unison and OCaml have changed their
"marshaling" or data serialization format over time. If the marshaling
formats are different, data could be corrupted. To prevent that, Unison
will quit if it connects to an incompatible version on the other end.

So this is a headache for packagers. We don't know what version might be
running on the other end, so we have to provide a bunch of different
versions, so users are likely to have one that works for them. The Unison
README.Cygwin file has more information.

This problem has been discussed a lot recently on the Unison lists. The
Unison devs are aware of it and are working towards a future release that
will start to preserve backwards compatibility if the marshaling format
changes again in the future.

Andrew



Re: New packages: unison2.51+4.04.2, unison2.51+4.10.0

2021-12-22 Thread Marco Atzeri

On 22.12.2021 17:21, Andrew Schulman via Cygwin-apps wrote:

Please add me as maintainer of two new unison packages:

unison2.51+4.04.2
unison2.51+4.10.0

These will obsolete the current unison2.51 package.

Thanks, Andrew



added.

Question: why Unison need all these versions ?

$ grep "unison" cygwin-pkg-maint
unison2.27   Andrew Schulman
unison2.32   Andrew Schulman
unison2.40   Andrew Schulman
unison2.45   Andrew Schulman
unison2.48   Andrew Schulman
unison2.48+4.04.2Andrew Schulman
unison2.48+4.08.1Andrew Schulman
unison2.49   Andrew Schulman
unison2.51   Andrew Schulman
unison2.51+4.04.2Andrew Schulman
unison2.51+4.10.0Andrew Schulman

Regards
Marco


New packages: unison2.51+4.04.2, unison2.51+4.10.0

2021-12-22 Thread Andrew Schulman via Cygwin-apps
Please add me as maintainer of two new unison packages:

unison2.51+4.04.2
unison2.51+4.10.0

These will obsolete the current unison2.51 package.

Thanks, Andrew



Re: python-odf

2021-12-22 Thread Jon Turney

On 22/12/2021 13:17, Marco Atzeri wrote:

On 20.12.2021 23:14, Marco Atzeri wrote:

Hi Jon,
while updating python-odf for the 3.9 round I noticed that for 1.4.1-1
I wrongly set a arch package instead of noarch as was for 0.9.5-1.

To solve the issue I copied the content of

/sourceware/ftp/anonftp/pub/cygwin/x86_64/release/python-odf
on
/sourceware/ftp/anonftp/pub/cygwin/noarch/release/python-odf


and removed the

/sourceware/ftp/anonftp/pub/cygwin/x86_64/release/python-odf
/sourceware/ftp/anonftp/pub/cygwin/x86/release/python-odf

I assume the modification should propagate at the next full rebuild 
(that I can not trigger)


I plan tomorrow to deploy almost all python packages


it seems to have worked

Yes, this is fine.

It's perhaps slightly non-ideal because it changes the published hash 
for the x86 python-odf 0.9.5-1 package, but I don't think this actually 
causes any problems.


(setup doesn't know the package has changed, so doesn't reinstall it, 
but that's not a problem as the contents are the same. There's perhaps 
some room for a setup feature where it records the hash of installed 
packages so it can notice this situation.)


(There used to be issues where setup would notice the a package in the 
package download cache with a mismatched hash and stop, but I think that 
is no longer the case and setup now evicts such packages from the 
package download cache.  But I don't think that applies in this case 
because a different download path will cause this package to be located 
in a different place in the package download cache)


Re: python-odf

2021-12-22 Thread Marco Atzeri

On 20.12.2021 23:14, Marco Atzeri wrote:

Hi Jon,
while updating python-odf for the 3.9 round I noticed that for 1.4.1-1
I wrongly set a arch package instead of noarch as was for 0.9.5-1.

To solve the issue I copied the content of

/sourceware/ftp/anonftp/pub/cygwin/x86_64/release/python-odf
on
/sourceware/ftp/anonftp/pub/cygwin/noarch/release/python-odf


and removed the

/sourceware/ftp/anonftp/pub/cygwin/x86_64/release/python-odf
/sourceware/ftp/anonftp/pub/cygwin/x86/release/python-odf

I assume the modification should propagate at the next full rebuild 
(that I can not trigger)


I plan tomorrow to deploy almost all python packages




it seems to have worked

Regards
Marco