ugrade mingw32-libunistring problem

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

ugrade mingw32-libunistring problem

waterlan
Hi,

I upgraded mingw32-libunistring to version 0.9.6, but in the catalogue
the version sticks to 0.9.3.

I updated file contrib/mingw32-libunistring.xml, and did a normal build.
Only contrib/issue.log changed, and there was only one unpublished file:
contrib/unpublished/mingw32-libunistring.xml.lzma.
I'm not sure if this is normal. Normally common/issue.log also changes,
and there are new packet list lzma files generated.

I did upload everything.

regards,


--
Erwin Waterlander
http://waterlan.home.xs4all.nl/

------------------------------------------------------------------------------
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: ugrade mingw32-libunistring problem

waterlan
waterlan schreef op 2016-01-05 07:05:

> Hi,
>
> I upgraded mingw32-libunistring to version 0.9.6, but in the catalogue
> the version sticks to 0.9.3.
>
> I updated file contrib/mingw32-libunistring.xml, and did a normal
> build.
> Only contrib/issue.log changed, and there was only one unpublished
> file:
> contrib/unpublished/mingw32-libunistring.xml.lzma.
> I'm not sure if this is normal. Normally common/issue.log also changes,
> and there are new packet list lzma files generated.
>
> I did upload everything.

I see that /mingw/var/lib/mingw-get/data/mingw32-libunistring.xml
doesn't get updated when I update the catalogue.
What is wrong?

--
Erwin Waterlander
http://waterlan.home.xs4all.nl/

------------------------------------------------------------------------------
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: ugrade mingw32-libunistring problem

waterlan
waterlan schreef op 2016-01-06 21:42:

> waterlan schreef op 2016-01-05 07:05:
>> Hi,
>>
>> I upgraded mingw32-libunistring to version 0.9.6, but in the catalogue
>> the version sticks to 0.9.3.
>>
>> I updated file contrib/mingw32-libunistring.xml, and did a normal
>> build.
>> Only contrib/issue.log changed, and there was only one unpublished
>> file:
>> contrib/unpublished/mingw32-libunistring.xml.lzma.
>> I'm not sure if this is normal. Normally common/issue.log also
>> changes,
>> and there are new packet list lzma files generated.
>>
>> I did upload everything.
>
> I see that /mingw/var/lib/mingw-get/data/mingw32-libunistring.xml
> doesn't get updated when I update the catalogue.
> What is wrong?

I think the problem is that the packages in contrib are in the mingw32
package-list. I did not change an xml file under mingw32, so the update
of mingw32/issue.log is not triggered, and also common/issue.log.

I think the contrib folder should have its own package-list.xml file.
Or I could make a dummy change in the mingw32 package-list.

Keith, can you fix this?

I don't understand why Keith did not have this problem when he updated
xerces on 2013-10-28.

regards,

--
Erwin Waterlander
http://waterlan.home.xs4all.nl/

------------------------------------------------------------------------------
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: ugrade mingw32-libunistring problem

Keith Marshall-3
On 07/01/16 19:16, waterlan wrote:
> waterlan schreef op 2016-01-06 21:42:
>> I see that /mingw/var/lib/mingw-get/data/mingw32-libunistring.xml
>> doesn't get updated when I update the catalogue.
>> What is wrong?

I know I've been quite about this, but I have been looking into the
issue, since you raised it.

> I think the problem is that the packages in contrib are in the mingw32
> package-list. I did not change an xml file under mingw32, so the update
> of mingw32/issue.log is not triggered, and also common/issue.log.

Hmm.  Yes, I see an inconsistency in mingw32/mingw32-package-list.xml,
where its own time stamp remains older than the corresponding timestamp
for the mingw32-libunistring.xml recorded within it (in the published
copy).  The problem is that mingw32/issue.log contains no record of the
update to mingw32-libunistring.xml, because that is in contrib/issue.log

> I think the contrib folder should have its own package-list.xml file.

The contrib directory was always something of an afterthought, but yes,
I've come to this conclusion too.

> Or I could make a dummy change in the mingw32 package-list.

No, don't do that; let's fix it properly.  You could equally well force
it by manually bumping the timestamp for mingw32-package-list.xml in
mingw32/issue.log; although taboo, and just as much a kludge as making
an artificial catalogue change, that would work too, but it's better not
to rely on such kludges.

> Keith, can you fix this?

Yes, I am looking into it.

> I don't understand why Keith did not have this problem when he updated
> xerces on 2013-10-28.

I don't either.  Maybe it didn't propagate until the next formal update
in mingw32 itself, and I just didn't notice.

--
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F


------------------------------------------------------------------------------

_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ugrade mingw32-libunistring problem

Keith Marshall-3
On 07/01/16 22:35, Keith Marshall wrote:
> On 07/01/16 19:16, waterlan wrote:
>> Keith, can you fix this?
>
> Yes, I am looking into it.

Should be fixed, now.  Please check.

--
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F


------------------------------------------------------------------------------

_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ugrade mingw32-libunistring problem

waterlan
Keith Marshall schreef op 2016-01-08 00:28:
> On 07/01/16 22:35, Keith Marshall wrote:
>> On 07/01/16 19:16, waterlan wrote:
>>> Keith, can you fix this?
>>
>> Yes, I am looking into it.
>
> Should be fixed, now.  Please check.
>

Thanks. I will try it this evening and let you know.

I was thinking, perhaps it's even better to move all the contrib
packages to mingw32. Only mingw32 and msys need to remain.
When somebody would contribute an msys package, would that need another
contrib folder?
Open source is all about contribution, so I think it doesn't need a
separate folder.
Contribution can be perfectly safe when it goes via patches or pull
requests.

regards,

--
Erwin Waterlander
http://waterlan.home.xs4all.nl/

------------------------------------------------------------------------------
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: ugrade mingw32-libunistring problem

waterlan
In reply to this post by Keith Marshall-3
Keith Marshall schreef op 2016-01-08 00:28:
> On 07/01/16 22:35, Keith Marshall wrote:
>> On 07/01/16 19:16, waterlan wrote:
>>> Keith, can you fix this?
>>
>> Yes, I am looking into it.
>
> Should be fixed, now.  Please check.

It works.
Thanks a lot.

--
Erwin

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: ugrade mingw32-libunistring problem

Keith Marshall-3
In reply to this post by waterlan
On 08/01/16 06:58, waterlan wrote:
> I was thinking, perhaps it's even better to move all the contrib
> packages to mingw32. Only mingw32 and msys need to remain.

No; we segregated them for any one of a number of reasons[*], and I
don't see why these should be any less valid today.  I prefer to keep a
separate delivery infrastructure for these packages.

[*] Off the top of my head:

1) They are of lesser importance to the project, than those in mingw32
   and msys; (actually, it isn't likely that we would adopt contributed
   MSYS packages anyway, since they could violate the minimalist goal).

2) There was some concern that contributors might walk away, and not
   continue to maintain their contributions; (this in no way implies
   that *you* would do so, but I contributed Xerces-C because we needed
   it for mingw-dist's XML validation tool.  The version I provided is
   still perfectly adequate for that purpose, and I have no incentive
   beyond that, to keep abreast of upstream updates).

3) There is a possibility that we could choose to aggregate contributed
   packages into a separate delivery channel; keeping them separate at
   the outset makes it easier to accomplish that later.

--
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

contrib

waterlan
Keith Marshall schreef op 2016-01-08 22:22:

> On 08/01/16 06:58, waterlan wrote:
>> I was thinking, perhaps it's even better to move all the contrib
>> packages to mingw32. Only mingw32 and msys need to remain.
>
> No; we segregated them for any one of a number of reasons[*], and I
> don't see why these should be any less valid today.  I prefer to keep a
> separate delivery infrastructure for these packages.
>
> [*] Off the top of my head:
>
> 1) They are of lesser importance to the project, than those in mingw32

You should not underestimate the importance. It's very convenient for
users to have ready-to-use libraries at hand. Extra libraries make the
whole project more attractive. Porting a library can be difficult and
very time consuming.

>    and msys; (actually, it isn't likely that we would adopt contributed
>    MSYS packages anyway, since they could violate the minimalist goal).

Too minimalistic is also not good, this will make people go away.

> 2) There was some concern that contributors might walk away, and not
>    continue to maintain their contributions; (this in no way implies
>    that *you* would do so, but I contributed Xerces-C because we needed
>    it for mingw-dist's XML validation tool.  The version I provided is
>    still perfectly adequate for that purpose, and I have no incentive
>    beyond that, to keep abreast of upstream updates).

Main maintainers can also walk away. People walking away should not
influence the package structure.

> 3) There is a possibility that we could choose to aggregate contributed
>    packages into a separate delivery channel; keeping them separate at
>    the outset makes it easier to accomplish that later.

That is adding complexity. I would rather keep it simple.

regards,

--
Erwin Waterlander
http://waterlan.home.xs4all.nl/

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: contrib

Earnie Boyd
On 1/9/2016 4:03 AM, waterlan wrote:

> Keith Marshall schreef op 2016-01-08 22:22:
>> On 08/01/16 06:58, waterlan wrote:
>>> I was thinking, perhaps it's even better to move all the contrib
>>> packages to mingw32. Only mingw32 and msys need to remain.
>>
>> No; we segregated them for any one of a number of reasons[*], and I
>> don't see why these should be any less valid today.  I prefer to keep a
>> separate delivery infrastructure for these packages.
>>
>> [*] Off the top of my head:
>>
>> 1) They are of lesser importance to the project, than those in mingw32
>
> You should not underestimate the importance. It's very convenient for
> users to have ready-to-use libraries at hand. Extra libraries make the
> whole project more attractive. Porting a library can be difficult and
> very time consuming.
>
>>    and msys; (actually, it isn't likely that we would adopt contributed
>>    MSYS packages anyway, since they could violate the minimalist goal).
>
> Too minimalistic is also not good, this will make people go away.
>
>> 2) There was some concern that contributors might walk away, and not
>>    continue to maintain their contributions; (this in no way implies
>>    that *you* would do so, but I contributed Xerces-C because we needed
>>    it for mingw-dist's XML validation tool.  The version I provided is
>>    still perfectly adequate for that purpose, and I have no incentive
>>    beyond that, to keep abreast of upstream updates).
>
> Main maintainers can also walk away. People walking away should not
> influence the package structure.
>
>> 3) There is a possibility that we could choose to aggregate contributed
>>    packages into a separate delivery channel; keeping them separate at
>>    the outset makes it easier to accomplish that later.
>
> That is adding complexity. I would rather keep it simple.

It was discussed years ago on this list so the archives can be reviewed.
 If I recall correctly the contrib directory was intended to provide a
place for those applications that were built with MinGW but not
pertinent to the functioning of MinGW.  We decided to also use this
directory for any package that someone wanted to contribute.  The
installation mechanism we now have may or may not cause that need to be
revisited but I'm of the opinion that it should remain to help isolate
those packages that are not pertinent to the functioning of MinGW.

MSYS was never meant to become a Cygwin and therefore we discouraged
contributions of packages that required MSYS.  The only reason for a
package to be added to MSYS is if it is needed to do ./configure and
make.  Some packages are needed because of the embedded POSIx paths
created automatically in files.  For instance we needed perl as an MSYS
package because of autoconf's usage of it.

--
Earnie

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: contrib

Keith Marshall-3
On 11/01/16 16:05, Earnie wrote:
> On 1/9/2016 4:03 AM, waterlan wrote:
>> Keith Marshall schreef op 2016-01-08 22:22:
>>> 3) There is a possibility that we could choose to aggregate contributed
>>>    packages into a separate delivery channel; keeping them separate at
>>>    the outset makes it easier to accomplish that later.
>>
>> That is adding complexity. I would rather keep it simple.

It is already simple; as primary maintainer of mingw-dist, I have no
intention of changing what we have right now.  However, it was wrong
that someone attempted to aggregate the contrib packages into the
mingw32 core catalogue; for simplicity, they need their own.

> It was discussed years ago on this list so the archives can be reviewed.
>  If I recall correctly the contrib directory was intended to provide a
> place for those applications that were built with MinGW but not
> pertinent to the functioning of MinGW.  We decided to also use this
> directory for any package that someone wanted to contribute.  The
> installation mechanism we now have may or may not cause that need to be
> revisited but I'm of the opinion that it should remain to help isolate
> those packages that are not pertinent to the functioning of MinGW.

For "not pertinent" read "non-essential".

This was precisely the point I was trying to make; from both the users'
perspective, in FRS, and the maintainer's perspective, in mingw-dist, I
prefer to keep "contrib" and core packages separated.

> MSYS was never meant to become a Cygwin and therefore we discouraged
> contributions of packages that required MSYS.  The only reason for a
> package to be added to MSYS is if it is needed to do ./configure and
> make.  Some packages are needed because of the embedded POSIx paths
> created automatically in files.  For instance we needed perl as an MSYS
> package because of autoconf's usage of it.

Also a point I was trying to make; MSYS is minimal, to the extent that
it satisfies the specific objective of hosting a GNU build system.  It
achieves that goal already, without requiring contributed packages.  It
is a fork of cygwin, and user's who need additional capabilities should
just use cygwin; it is not our objective to compete with cygwin, (which
is why we do not sanction the MSYS2 project; they seem to be heading in
precisely the direction of direct competition with cygwin).

--
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

signature.asc (853 bytes) Download Attachment