From: Erwin W. <wat...@xs...> - 2011-10-12 18:35:50
|
Hi, My application (wcd) needs libunistring (http://www.gnu.org/s/libunistring/) for Unicode normalisation. I'm willing to package and maintain libunistring for Mingw. I already do this for Cygwin. I used portmaker to create the mingwPORT scripts. Libunistring compiles without problems, out-of-the-box, but at the very end the linking step ends with this error: libtool: link: gcc -shared .libs/libunistring.la.lnkscript -Lc:/msys/1.0/mingw/lib /mingw/lib/libiconv.dll.a -mms-bitfields -march=i686 -Wl,--export-all-symbols -Wl,--disable-auto-import -o .libs/libunistring-0.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libunistring.dll.a Creating library file: .libs/libunistring.dll.a glthread/.libs/lock.o:lock.c:(.text+0x14): undefined reference to `_imp__pthread_mutexattr_init' glthread/.libs/lock.o:lock.c:(.text+0x3d): undefined reference to `_imp__pthread_mutexattr_settype' glthread/.libs/lock.o:lock.c:(.text+0x54): undefined reference to `_imp__pthread_mutex_init' glthread/.libs/lock.o:lock.c:(.text+0x63): undefined reference to `_imp__pthread_mutexattr_destroy' glthread/.libs/lock.o:lock.c:(.text+0x79): undefined reference to `_imp__pthread_mutexattr_destroy' glthread/.libs/lock.o:lock.c:(.text+0x85): undefined reference to `_imp__pthread_mutexattr_destroy' collect2: ld returned 1 exit status make[2]: *** [libunistring.la] Error 1 make[2]: Leaving directory `/c/Users/waterlan/src/mingw/libunistring/mingwPORT/bld/lib' make[1]: *** [install] Error 2 make[1]: Leaving directory `/c/Users/waterlan/src/mingw/libunistring/mingwPORT/bld/lib' make: *** [install-recursive] Error 1 I have the latest pthreads installed: $ ls /mingw/lib/libpthr* /mingw/lib/libpthread.a /mingw/lib/libpthreadGC2.dll.a /mingw/lib/libpthread.dll.a /mingw/lib/libpthreadGCE2.dll.a Why is this last linking step going wrong? My initial mingwPORT scripts are here: http://waterlan.home.xs4all.nl/mingw/libunistring-0.9.3-1-mingwPORT.tar.bz2 best regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Charles W. <cwi...@us...> - 2011-10-12 19:21:15
|
On 10/12/2011 2:35 PM, Erwin Waterlander wrote: > My application (wcd) needs libunistring > (http://www.gnu.org/s/libunistring/) for Unicode normalisation. I'm > willing to package and maintain libunistring for Mingw. I already do > this for Cygwin. MinGW, at present, doesn't intend to be a repository of all possible packages ported to win32. Right now, the only packages we provide, in the -mingw32- subsystem, fall into two categories, with a few historical exceptions: 1) development tools like auto* (and gcc itself, with its supporting libraries, of course). This includes the libiconv and libintl libraries, because they are needed, in mingw form, in order for the gettextize tool (&friends) to work properly. 2) a few compression libraries (zlib, bzip, xz, libarchive) which are needed to support mingw-get.exe development. Stuff like PDCurses falls under the "historical exception" because long ago, there used to be a PDCurses mingwPORT "contrib" item, and somebody offered to update it to make it "mingw-get" compatible. We haven't really had the discussion about handling additional packages. I think that deserves its own thread, to consider the issues: What do we do about "contributed" mingw32 libraries and exes? Should they even be considered for acceptance as part of the mingw.org packageset? Should that be a separate project (with its own mingw-get-compatible repository?) OR, should it be managed as an intrinsic part of the "core" offerings here @ mingw.org? Policies & procedures? > I used portmaker to create the mingwPORT scripts. Libunistring compiles > without problems, out-of-the-box, FYI, you might want to try the new 'mgwport' package -- which should allow you to reuse (a lot of) your .cygport scripts from your cygwin package. Unlike portmaker/mingwPORT, mgwport is intended for creating binary tarballs for distribution. mingwPORT, OTOH, is meant for distributing "recipes" that end users can use to build the binaries themselves, and requires some hacking to make it work for the bindist purpose. > but at the very end the linking step > ends with this error: > > libtool: link: gcc -shared .libs/libunistring.la.lnkscript > -Lc:/msys/1.0/mingw/lib /mingw/lib/libiconv.dll.a -mms-bitfields > -march=i686 -Wl,--export-all-symbols -Wl,--disable-auto-import -o > .libs/libunistring-0.dll -Wl,--enable-auto-image-base -Xlinker > --out-implib -Xlinker .libs/libunistring.dll.a Because gcc is not invoked with -pthread (nor is -lpthread added to the link command). Why libtool is "doing it wrong" I don't know, you'll have to investigate. (FWIW, the use of a link script '.libs/libunistring.la.lnkscript' looks suspicious to me) -- Chuck |
From: Erwin W. <wat...@xs...> - 2011-10-12 20:38:22
|
Charles Wilson schreef, Op 12-10-2011 21:21: > MinGW, at present, doesn't intend to be a repository of all possible > packages ported to win32. Right now, the only packages we provide, in > the -mingw32- subsystem, fall into two categories, with a few historical > exceptions: > > 1) development tools like auto* (and gcc itself, with its > supporting libraries, of course). This includes the > libiconv and libintl libraries, because they are needed, in > mingw form, in order for the gettextize tool (&friends) to > work properly. > 2) a few compression libraries (zlib, bzip, xz, libarchive) > which are needed to support mingw-get.exe development. > > Stuff like PDCurses falls under the "historical exception" because long > ago, there used to be a PDCurses mingwPORT "contrib" item, and somebody > offered to update it to make it "mingw-get" compatible. I packaged PDCurses for mingw. I think that handling Unicode strings is basic functionality nowadays. What libc offers in not enough. Libunistring is a good extension. > > We haven't really had the discussion about handling additional packages. > I think that deserves its own thread, to consider the issues: What do > we do about "contributed" mingw32 libraries and exes? Should they even > be considered for acceptance as part of the mingw.org packageset? Should > that be a separate project (with its own mingw-get-compatible > repository?) OR, should it be managed as an intrinsic part of the > "core" offerings here @ mingw.org? Policies& procedures? I would like a central repository with all kinds of mingw packages very much. My preference would be to have it under mingw, or very close to it. This is much better than having packages spread all over the internet, or lots of people that struggle with porting the same package. Until then I will offer libunistring for mingw on my own home page. And if you still want it, I package it for mingw. > >> I used portmaker to create the mingwPORT scripts. Libunistring compiles >> without problems, out-of-the-box, > FYI, you might want to try the new 'mgwport' package -- which should > allow you to reuse (a lot of) your .cygport scripts from your cygwin > package. > > Unlike portmaker/mingwPORT, mgwport is intended for creating binary > tarballs for distribution. mingwPORT, OTOH, is meant for distributing > "recipes" that end users can use to build the binaries themselves, and > requires some hacking to make it work for the bindist purpose. OK. That sounds very good. But as long as there is no intention to take libunistring, I will not try it. -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Erwin W. <wat...@xs...> - 2011-10-13 07:58:22
|
On 10/12/2011 10:38 PM, Erwin Waterlander wrote: > Charles Wilson schreef, Op 12-10-2011 21:21: >> We haven't really had the discussion about handling additional packages. >> I think that deserves its own thread, to consider the issues: What do >> we do about "contributed" mingw32 libraries and exes? Should they even >> be considered for acceptance as part of the mingw.org packageset? Should >> that be a separate project (with its own mingw-get-compatible >> repository?) OR, should it be managed as an intrinsic part of the >> "core" offerings here @ mingw.org? Policies& procedures? > > I would like a central repository with all kinds of mingw packages > very much. My preference would be to have it under mingw, or very > close to it. This is much better than having packages spread all over > the internet, or lots of people that struggle with porting the same > package. > > Until then I will offer libunistring for mingw on my own home page. > And if you still want it, I package it for mingw. > Hi, I will create packages according the mingw standards. Then you can always decide later if you want to add them to the mingw repository. Do you mind if I would announce these packages on MinGW mailing list? Erwin |
From: Earnie <ea...@us...> - 2011-10-13 12:45:25
|
Erwin Waterlander wrote: > I will create packages according the mingw standards. Then you can > always decide later if you want to add them to the mingw repository. > Use Chuck's mgwport so that all the xml niceties are in place. I think we could/should allow https://sourceforge.net/projects/mingw/files/UserContributed/ to be the path of distribution for this. > Do you mind if I would announce these packages on MinGW mailing list? Expected if you upload it to the project. Otherwise I am leery of making an exception foreseeing others doing the same. Earnie |
From: Erwin W. <wat...@xs...> - 2011-10-13 17:20:11
|
Earnie schreef, Op 13-10-2011 14:45: > Use Chuck's mgwport so that all the xml niceties are in place. I think > we could/should allow > https://sourceforge.net/projects/mingw/files/UserContributed/ to be > the path of distribution for this. I see the old PDCursus under there, while the new one is under http://sourceforge.net/projects/mingw/files/MinGW/PDCurses/ Perhaps it's better to have a separate contrib folder for MinGW and MSYS , for instance http://sourceforge.net/projects/mingw/files/MinGW/Contrib/ and http://sourceforge.net/projects/mingw/files/MSYS/Contrib/ On the other hand, I don't see why these packages can't be straight under MinGW/ or MSYS/, like the current PDCurses. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Erwin W. <wat...@xs...> - 2011-10-13 20:51:39
|
Earnie schreef, Op 13-10-2011 14:45: > Use Chuck's mgwport so that all the xml niceties are in place. I have a few questions. Does that mean that an xml file is automatically generated? The standard libunistring package doesn't install any copyright file. It seems that for mingw a 'lic' package is required. How do I deal with that? I used msys-autoconf and msys-automake when I installed libunistring from the standard package. It worked without problems. Do I need to use mingw-autoconf and mingw-automake when I use mgwport? This is my mgwport so far: http://waterlan.home.xs4all.nl/mingw/libunistring.tar.gz -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Charles W. <cwi...@us...> - 2011-10-13 22:52:54
|
On 10/13/2011 4:51 PM, Erwin Waterlander wrote: > Earnie schreef, Op 13-10-2011 14:45: >> Use Chuck's mgwport so that all the xml niceties are in place. > > I have a few questions. > > Does that mean that an xml file is automatically generated? No; I'm not exactly sure what Earnie meant by that comment. He may have been referring to the ongoing discussion concerning pre/post-install scripts and mingw-get. Currently, mgwport can/may create vestigial pre/post install scripts which would be shipped in /etc/postinstall/ and /etc/preremove -- but mingw-get won't execute them. There has been some talk about including actual script fragments in the mingw-get .xml manifests themselves. If that happens, mgwport might be able to generate (some of) the appropriate fragments for that scripting language automatically -- but they would need to be manually pasted into the actual .xml manifest, and checked-in to mingw-dist, uploaded to the catalogue database separately, etc. Anyway, that's all in the future. > The standard libunistring package doesn't install any copyright file. It > seems that for mingw a 'lic' package is required. How do I deal with that? If the src package includes one -- like "COPYING" or somesuch, then add the following: DOCS="COPYING" in your .mgwport, outside of any func() definitions. > I used msys-autoconf and msys-automake when I installed libunistring > from the standard package. It worked without problems. Do I need to use > mingw-autoconf and mingw-automake when I use mgwport? It probably didn't *hurt* you, but it *could*. The mingw libtool and the msys libtool differ slightly, for one thing, and msys-autoreconf will use msys-libtoolize rather than mingw-libtoolize. > This is my mgwport so far: > http://waterlan.home.xs4all.nl/mingw/libunistring.tar.gz I'll take a look later. -- Chuck |
From: Erwin W. <wat...@xs...> - 2011-10-15 06:04:33
|
Charles Wilson schreef, Op 14-10-2011 0:52: >> This is my mgwport so far: >> http://waterlan.home.xs4all.nl/mingw/libunistring.tar.gz > I'll take a look later. > I removed it. I put an updated package soon. -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Erwin W. <wat...@xs...> - 2011-10-15 09:11:03
|
Erwin Waterlander schreef, Op 15-10-2011 8:04: > Charles Wilson schreef, Op 14-10-2011 0:52: >>> This is my mgwport so far: >>> http://waterlan.home.xs4all.nl/mingw/libunistring.tar.gz >> I'll take a look later. >> > I removed it. I put an updated package soon. > Hi, I have now a more complete source package. http://waterlan.home.xs4all.nl/mingw/libunistring.tar.bz2 But mgwport stops installation, because it lacks 'realpath'. I didn't have this problem when I installed it from the original source, but then I had gnuwin32's realpath in PATH. Does mingw provide realpath? regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Charles W. <cwi...@us...> - 2011-10-16 03:53:33
Attachments:
libunistring-0.9.3-1-mingw32-src.tar.lzma
|
On 10/15/2011 5:10 AM, Erwin Waterlander wrote: > I have now a more complete source package. > http://waterlan.home.xs4all.nl/mingw/libunistring.tar.bz2 > But mgwport stops installation, because it lacks 'realpath'. I don't see this issue. With one change to the .mgwport (ensuring that COPYING and COPYING.LIB end up only in the -lic package, and not both -lic and -doc), it builds completely. It also passes the checks: ======================= All 399 tests passed (18 tests were not run) ======================= > I didn't have this problem when I installed it from the original source, > but then I had gnuwin32's realpath in PATH. Does mingw provide realpath? Odd. Are you sure you didn't build from inside an "msys developer" shell (e.g. where uname report MSYS) rather than a normal mingw shell (where uname reports MinGW)? I've attached the -src package (which I modified, removing the upstream 'real' source tarball for size issues). Just do mgwport libunistring-0.9.3-1.mgwport download to d/l that tarball as a 'repair'. Then mgwport libunistring-0.9.3-1.mgwport almostall works just fine for me. BTW, I did see a lot of warnings during the 'autoreconf' step, similar to this: configure.ac:55: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body but that's because the existing .m4 files in the package have not been updated as required by autoconf-2.68. It doesn't appear to do any harm, but if you were really picky you might want to patch 'em up to the latest requirements so that ac-2.68 stops complaining. However, since it appears that many of the warnings are coming from gnulib contributions...that's a LOT of m4 to patch. You could just ignore it -- it seems to be ok. Fallback solution: add gcc-tools-epoch2-autoconf gcc-tools-epoch2-automake to your build environment (and build-requires documentation), and add the following to the .mgwport (outside of any src_function() body): PATH="/mingw/opt/gcc-tools/epoch2/bin:${PATH}" This will cause the auto* to be taken from that alternate location, and the version(s) there are 2.64 which is another way to silence the warnings. -- Chuck |
From: Erwin W. <wat...@xs...> - 2011-10-16 07:31:30
|
Charles Wilson schreef, Op 16-10-2011 5:53: > On 10/15/2011 5:10 AM, Erwin Waterlander wrote: >> I have now a more complete source package. >> http://waterlan.home.xs4all.nl/mingw/libunistring.tar.bz2 >> But mgwport stops installation, because it lacks 'realpath'. > > I don't see this issue. With one change to the .mgwport (ensuring > that COPYING and COPYING.LIB end up only in the -lic package, and not > both -lic and -doc), it builds completely. It also passes the checks: > > ======================= > All 399 tests passed > (18 tests were not run) > ======================= > >> I didn't have this problem when I installed it from the original source, >> but then I had gnuwin32's realpath in PATH. Does mingw provide realpath? > > Odd. Are you sure you didn't build from inside an "msys developer" > shell (e.g. where uname report MSYS) rather than a normal mingw shell > (where uname reports MinGW)? When I start from scratch, I also don't have the problem any more. I think it was caused because the gnuwin32 binary was in PATH during configure, and I deleted while libunistring was building. > > I've attached the -src package (which I modified, removing the > upstream 'real' source tarball for size issues). Just do > > mgwport libunistring-0.9.3-1.mgwport download > > to d/l that tarball as a 'repair'. Then > > mgwport libunistring-0.9.3-1.mgwport almostall > > works just fine for me. > > BTW, I did see a lot of warnings during the 'autoreconf' step, similar > to this: > > configure.ac:55: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call > detected in body > > but that's because the existing .m4 files in the package have not been > updated as required by autoconf-2.68. It doesn't appear to do any > harm, but if you were really picky you might want to patch 'em up to > the latest requirements so that ac-2.68 stops complaining. However, > since it appears that many of the warnings are coming from gnulib > contributions...that's a LOT of m4 to patch. You could just ignore it > -- it seems to be ok. > > Fallback solution: add > gcc-tools-epoch2-autoconf > gcc-tools-epoch2-automake > to your build environment (and build-requires documentation), and add > the following to the .mgwport (outside of any src_function() body): > > PATH="/mingw/opt/gcc-tools/epoch2/bin:${PATH}" > > This will cause the auto* to be taken from that alternate location, > and the version(s) there are 2.64 which is another way to silence the > warnings. > > -- > Chuck > Thanks. I'm not so picky, so I just ignore the m4 warnings. I created a full set of mingw32 packages. See http://waterlan.home.xs4all.nl/mingw/ Now I need an xml file and a place to upload. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Erwin W. <wat...@xs...> - 2011-10-21 08:16:52
|
Op 16-10-2011 9:31, Erwin Waterlander schreef: > Thanks. I'm not so picky, so I just ignore the m4 warnings. I created a > full set of mingw32 packages. See > http://waterlan.home.xs4all.nl/mingw/ > > Now I need an xml file and a place to upload. > > regards, > Is there enough consensus about contributions, such that the packages can be uploaded to MinGW/Contrib/? To have them already available for manual installation. best regards, -- Erwin Waterlander www: http://waterlan.home.xs4all.nl/ |
From: Earnie <ea...@us...> - 2011-10-23 23:43:48
|
Ping Erwin Waterlander wrote: > Op 16-10-2011 9:31, Erwin Waterlander schreef: >> Thanks. I'm not so picky, so I just ignore the m4 warnings. I created a >> full set of mingw32 packages. See >> http://waterlan.home.xs4all.nl/mingw/ >> >> Now I need an xml file and a place to upload. >> >> regards, >> > > Is there enough consensus about contributions, such that the packages > can be uploaded to MinGW/Contrib/? To have them already available for > manual installation. > > best regards, > |
From: Charles W. <cwi...@us...> - 2011-10-24 00:21:31
|
On 10/23/2011 7:43 PM, Earnie wrote: > Ping > > Erwin Waterlander wrote: >> Is there enough consensus about contributions, such that the packages >> can be uploaded to MinGW/Contrib/? To have them already available for >> manual installation. Waiting on a proposed mingw-get manifest xml file. -- Chuck |
From: Erwin W. <wat...@xs...> - 2011-10-24 12:41:19
|
On 10/24/2011 2:21 AM, Charles Wilson wrote: > On 10/23/2011 7:43 PM, Earnie wrote: >> Ping >> >> Erwin Waterlander wrote: >>> Is there enough consensus about contributions, such that the packages >>> can be uploaded to MinGW/Contrib/? To have them already available for >>> manual installation. > Waiting on a proposed mingw-get manifest xml file. > OK, I will propose one. Where can I find a good example? Erwin |
From: Charles W. <cwi...@us...> - 2011-10-24 14:52:29
|
On 10/24/2011 8:41 AM, Erwin Waterlander wrote: > On 10/24/2011 2:21 AM, Charles Wilson wrote: >> Waiting on a proposed mingw-get manifest xml file. >> > > OK, I will propose one. Where can I find a good example? http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get/catalogue/ ...also, the current ones are all stored, in uncompressed form, in /mingw/var/lib/mingw-get/data/ I'd look at mingw32-bzip2. -- Chuck |
From: Charles W. <cwi...@us...> - 2011-10-28 03:15:48
|
On 10/27/2011 3:39 PM, Erwin Waterlander wrote: > I added a proposed xml manifest file: > > http://waterlan.home.xs4all.nl/mingw/mingw32-libunistring.xml.lzma > > http://waterlan.home.xs4all.nl/mingw/libunistring-0.9.3-1-mingw32-dev.tar.lzma > http://waterlan.home.xs4all.nl/mingw/libunistring-0.9.3-1-mingw32-dll-0.tar.lzma > http://waterlan.home.xs4all.nl/mingw/libunistring-0.9.3-1-mingw32-doc.tar.lzma > http://waterlan.home.xs4all.nl/mingw/libunistring-0.9.3-1-mingw32-lic.tar.lzma > http://waterlan.home.xs4all.nl/mingw/libunistring-0.9.3-1-mingw32-src.tar.lzma > http://waterlan.home.xs4all.nl/mingw/libunistring-0.9.3-1-mingw32.RELEASE_NOTES.txt Looks good. One minor quibble: for the -dev package, I'd add the libunistring dll package as a <requires/>, but /not/ libgcc-dll or libintl-dll. I mean, unistring.h doesn't really *require* libgcc-dll, does it? That is: <component class="dev"> <release tarname="libunistring-0.9.3-1-mingw32-dev.tar.lzma" > - <requires eq="mingw32-libgcc-*-mingw32-dll-1.tar" /> - <requires eq="mingw32-libiconv-*-mingw32-*-dll-2.tar" /> + <requires eq="mingw32-libunistring-%-mingw32-%-dll-0.tar" /> </release> </component> Now, to skip ahead to the next question...when we upload this, should we go ahead and move PDCurses into MinGW/Contributed/ as well? (Unless somebody has an argument for why PDCurses should be "core") -- Chuck |
From: Keith M. <kei...@us...> - 2011-10-28 17:26:36
|
On 28/10/11 04:15, Charles Wilson wrote: > One minor quibble: for the -dev package, I'd add the > libunistring dll package as a <requires/>, but /not/ libgcc-dll or > libintl-dll. I mean, unistring.h doesn't really *require* libgcc-dll, > does it? To be pedantic, it probably doesn't *require* libunistring-dll either, but let's not reopen that can of worms... > That is: > > <component class="dev"> > <release tarname="libunistring-0.9.3-1-mingw32-dev.tar.lzma" > > - <requires eq="mingw32-libgcc-*-mingw32-dll-1.tar" /> > - <requires eq="mingw32-libiconv-*-mingw32-*-dll-2.tar" /> > + <requires eq="mingw32-libunistring-%-mingw32-%-dll-0.tar" /> > </release> > </component> ... is certainly more appropriate; the further dependency on libgcc-dll and libintl-dll is really a property of libunistring-dll, and will thus be resolved (recursively), when that is installed. One further quibble, (also minor): there should be an <affiliate ... /> declaration [1], e.g.: <package name="mingw32-libunistring" alias="libunistring"> + <affiliate group="MinGW Contributed Libraries" /> + <description lang="en" title="libunistring: ... so mingw-get will categorise it appropriately; (this will become more important when we have a GUI implementation, which can display lists of available packages filtered by category, but let's pre-empt that now). Also, maybe consider renaming RELEASE_NOTES.txt as README.txt, so it will be rendered directly in the browser view of the FRS download page. > Now, to skip ahead to the next question...when we upload this, should we > go ahead and move PDCurses into MinGW/Contributed/ as well? IMO, yes. > (Unless somebody has an argument for why PDCurses should be "core") None that I can think of. [1] I guess we need a further discussion, to formalise the categories for group affiliation. As a starting point, I propose [2]: MinGW MinGW Base System MinGW Development Tools MinGW Contributed MinGW Contributed Libraries MinGW Contributed Utilities MSYS MSYS Base System MSYS Development Tools MSYS Contributed MSYS Contributed Libraries MSYS Contributed Utilities possibly augmented to include (some of) the tentative categories which are already declared in the <package-group-hierarchy ... /> structure defined in the existing *-package-list.xml files. [2] I'll start a new thread, to take this discussion forward. -- Regards, Keith. |
From: Erwin W. <wat...@xs...> - 2011-10-31 08:19:20
|
On 10/28/2011 11:47 AM, Keith Marshall wrote: > One further quibble, (also minor): there should be an<affiliate ... /> > declaration [1], e.g.: > > <package name="mingw32-libunistring" alias="libunistring"> > +<affiliate group="MinGW Contributed Libraries" /> > + > <description lang="en" title="libunistring: ... Hi, I added the proposed affiliate declaration to the xml file. regards, Erwin |
From: Keith M. <kei...@us...> - 2011-10-24 16:57:11
Attachments:
mkxml-example.tar.xz
|
On 24/10/11 01:21, Charles Wilson wrote: >> Erwin Waterlander wrote: >>> Is there enough consensus about contributions, such that the packages >>> can be uploaded to MinGW/Contrib/? To have them already available for >>> manual installation. > > Waiting on a proposed mingw-get manifest xml file. Which may be facilitated by the attached script fragment, abstracted from my packaging tool kit; (you'll need to adapt my pkgspec format to fit whatever you have for mgwport, or vice-versa). Run it, (it needs a working groff installation), as sh xmltest.sh ./lua-5.1.4-1-mingw32.pkgspec to reproduce my example for lua. -- Regards, Keith. |
From: Erwin W. <wat...@xs...> - 2011-10-14 07:22:13
|
On 10/14/2011 12:52 AM, Charles Wilson wrote: > > >> The standard libunistring package doesn't install any copyright file. It >> seems that for mingw a 'lic' package is required. How do I deal with that? > If the src package includes one -- like "COPYING" or somesuch, then add > the following: > > DOCS="COPYING" > > in your .mgwport, outside of any func() definitions. > > Do I need to copy this file into MINGW-PATCHES first, or is the DOCS list relative to the original package contents? Erwin |
From: Charles W. <cwi...@us...> - 2011-10-14 14:31:30
|
On 10/14/2011 3:22 AM, Erwin Waterlander wrote: > Do I need to copy this file into MINGW-PATCHES first, or is the DOCS > list relative to the original package contents? The latter -- in [cyg|mgw]port terms, it is relative to the ${S} directory. -- Chuck |
From: Charles W. <cwi...@us...> - 2011-11-01 13:48:31
|
On 10/31/2011 4:19 AM, Erwin Waterlander wrote: > On 10/28/2011 11:47 AM, Keith Marshall wrote: >> One further quibble, (also minor): there should be an<affiliate ... /> >> declaration [1], e.g.: >> >> <package name="mingw32-libunistring" alias="libunistring"> >> +<affiliate group="MinGW Contributed Libraries" /> >> + >> <description lang="en" title="libunistring: ... > > Hi, > > I added the proposed affiliate declaration to the xml file. I uploaded the packages to frs, using 'MinGW/Contributed/libunistring'. I also uploaded the manifest, with the affiliate group above, to the catalogues/ directory. I did **not** do the following: 1) $whatever is required, in mingw-dist, to cause mingw32-libunistring.xml.lzma to be "included" in mingw-get's working set -- mainly because I wasn't sure what was required, when the .xml file is not maintained in mingw-dist itself. 2) Move MinGW/PDCurses/ to MinGW/Contributed/PDCurses -- because (a) I'm not sure if sftp allows to "move" directories. It provides a 'rename' command, and I tried: rename PDCurses Contributed/PDCurses but that failed, because either (a) rename doesn't allow that operation, or (b) I didn't have appropriate permissions. [*] If it is a limitation of the rename command, then the alternative (which avoids downloading and re-uploading everything) is to recreate the directory structure in the new location, then to use sftp's 'ln' command to create hardlinks to all the files, and finally to remove the "old" files. Of course, I'd test one file first (with d/l'ed backup) just to make sure sftp ln does what I think, before deleting ALL the files from the old location... 3) Remove mingw32/mingw32-pdcurses.xml from mingw-dist, and $whatever is required to make mingw-get still USE the sf.net-based mingw32-pdcurses.xml.lzma, while allowing mingw-dist's build procedure to "skip" trying to build the file (maybe nothing?). [*] Pet peeve: please, when you upload to sf.net, or create new directories, make sure the chmod all dirs as 775, and all files as 664. Erwin "owns" the PDCurses directory (rwxr-xr-x), so I couldn't move it. There are quite a few other dirs and files without group write permission. If you have access to frs, please log on and fix the files that you can. Earnie: is there any way to make sure the default "remote umask" on frs is 002, not 022? Or is there a way to make that "sticky" -- at least under the MinGW/, MSYS/, and Automated MinGW Installer/ directories? Alternatively, can we manipulate the frs from an ssh session -- and if so, who has the requisite administrative karma to turn rw-r--r-- into rw-rw-r-- on existing files which are owned by another project member? -- Chuck |