From: Chris S. <ir0...@gm...> - 2010-09-09 20:10:56
Attachments:
mingw32-gdb.xml
mingw32-runtime.xml
|
Hi Chuck / Keith, I have to admit, the layout of these new XML files confuses me. Can you please take a look at the attached files before I commit them and use them to generate the files for mingw-get? Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Charles W. <cwi...@us...> - 2010-09-09 20:39:02
Attachments:
mingw32-gdb.xml
mingw32-runtime.xml
|
On 9/9/2010 4:10 PM, Chris Sutcliffe wrote: > Hi Chuck / Keith, Don't expect to hear from Keith; he's already warned us he might not even have email access between now and mid-October. > I have to admit, the layout of these new XML files confuses me. Can > you please take a look at the attached files before I commit them and > use them to generate the files for mingw-get? Here's how I would do it. (I haven't tested these yet; I'll do that in a few hours). -- Chuck |
From: Chris S. <ir0...@gm...> - 2010-09-09 20:55:34
|
Hi Chuck, On 9 September 2010 16:38, Charles Wilson wrote: > On 9/9/2010 4:10 PM, Chris Sutcliffe wrote: >> Hi Chuck / Keith, > > Don't expect to hear from Keith; he's already warned us he might not > even have email access between now and mid-October. Thank you for the heads up. I saw Keith's email about him being busy until mid-October, but wasn't aware that it would also affect his email access. >> I have to admit, the layout of these new XML files confuses me. Can >> you please take a look at the attached files before I commit them and >> use them to generate the files for mingw-get? > > Here's how I would do it. (I haven't tested these yet; I'll do that in a > few hours). >From the runtime xml file: <licence tarname="w32api-%-mingw32-dev.tar" /> <source tarname="w32api-%-mingw32-src.tar" /> will this work when the file format is w32api-3.15-1-mingw32-dev/src.tar.lzma? Meaning will the '%' match 3.15-1? My assumption was that it needed to match based on the hyphen. Additionally, is the '.tar' sufficient, or should it be '.tar.lzma'? Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Charles W. <cwi...@us...> - 2010-09-09 22:26:35
|
On 9/9/2010 4:55 PM, Chris Sutcliffe wrote: > On 9 September 2010 16:38, Charles Wilson wrote: >> Here's how I would do it. (I haven't tested these yet; I'll do that in a >> few hours). > > From the runtime xml file: > > <licence tarname="w32api-%-mingw32-dev.tar" /> > <source tarname="w32api-%-mingw32-src.tar" /> > > will this work when the file format is > w32api-3.15-1-mingw32-dev/src.tar.lzma? Meaning will the '%' match > 3.15-1? Yes, it will. > My assumption was that it needed to match based on the > hyphen. These values are not literal regexes, they are smarter than that. They are field specifiers...and since the RELEASE (and BUILD) field(s) may or may not be present, then a '%' will match the entire group of fields whose position it spans (e.g. all the stuff between NAME and SUBSYS, in this case -- which is VER, REL, and BUILD). > Additionally, is the '.tar' sufficient, or should it be > '.tar.lzma'? That's a very good question; I don't know. I suspect it should be .tar.lzma (or actually .tar.gz in the case of w32api), but many of the existing xml's don't include the compression schema. This is fine for <requires > specifications -- but it might not be so great for tarname attributes! I'd add the .gz in this case, but for the rest of the various xmls...no need to borrow trouble. Right now mingw-get doesn't use the <source> and <licence> entries, so...there's no hurry. -- Chuck |
From: Charles W. <cwi...@us...> - 2010-09-10 00:24:13
Attachments:
xml-updates.patch
|
On 9/9/2010 6:26 PM, Charles Wilson wrote: > On 9/9/2010 4:55 PM, Chris Sutcliffe wrote: >> On 9 September 2010 16:38, Charles Wilson wrote: >>> Here's how I would do it. (I haven't tested these yet; I'll do that in a >>> few hours). ... > I'd add the .gz in this case, OK, I added the missing .gz, and tested the result. Seems to work fine. Here are the new xml files, presented as a patch against current CVS. (Before committing, be sure to do a build yourself, so that mingw32/issue.log gets updated appropriately. Then verify it, and check it in along with the two files modified below. I've attributed the xml changes to you in the changelog entry below, since you're actually the guy that updated the gdb and mingwrt packages themselves. 2010-09-10 Chris Sutcliffe <...> Update & publish mingw32-{gdb,runtime} * mingw32/mingw32-gdb.xml: Clean up formatting; add source and licence specifications; add new doc component; generate and publish mingw32-gdb.xml.lzma. * mingw32/mingw32-runtime.xml: Clean up formatting; reduce to deliver only the latest available releases; restore mingw-runtime alias; add source and licence specifications; ensure -dev component requires -dll component; generate and publish mingw32-runtime.xml.lzma. * mingw32/issue.log: Updated accordingly. -- Chuck |
From: Chris S. <ir0...@gm...> - 2010-09-10 01:17:54
|
On 9 September 2010 18:26, Charles Wilson wrote: >> Additionally, is the '.tar' sufficient, or should it be >> '.tar.lzma'? > > That's a very good question; I don't know. I suspect it should be > .tar.lzma (or actually .tar.gz in the case of w32api), but many of the > existing xml's don't include the compression schema. This is fine for > <requires > specifications -- but it might not be so great for tarname > attributes! Actually it is .tar.lzma as of the 3.15 release (at least for MinGW), I updated the 'dist' target for MinGW to follow the newer naming standard and preferred compression format. > I'd add the .gz in this case, but for the rest of the various xmls...no > need to borrow trouble. Right now mingw-get doesn't use the <source> > and <licence> entries, so...there's no hurry. As mention, .lzma is appropriate. Cheers! Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Chris S. <ir0...@gm...> - 2010-09-10 02:04:39
Attachments:
Makefile.comm.in.patch
|
Looks like there is a bug in Makefile.comm.in that resulted in: $ make make[1]: Entering directory `/src/installer/build/common' ../Makefile.comm:52: Makefile.sub: No such file or directory test -d unpublished || mkdir unpublished echo "auto-distfiles = \\" > Makefile.sub for file in ../../mingw-dist/common/package-list.xml; do echo "$file.lzma \\" | sed 's,.*/, ,' >> Makefile.sub; done echo ' $(EXTRA_DISTFILES)' >> Makefile.sub make[1]: Leaving directory `/src/installer/build/common' make[1]: Entering directory `/src/installer/build/common' test -d unpublished || mkdir unpublished rm -rf tmp cvs -z3 -Q -d `cat ../../mingw-dist/common/CVS/Root` checkout -A -d tmp `cat ../../mingw-dist/common/CVS/Repository`/issue.log ir0...@mi...'s password: rm -f ../../mingw-dist/common/issue.log; mv tmp/issue.log ../../mingw-dist/common/issue.log cp -p ../../../mingw-dist/common/issue.log tmp cp: cannot stat `../../../mingw-dist/common/issue.log': No such file or directory make[1]: *** [all-sync-to-cvs-or-offline] Error 1 make[1]: Leaving directory `/src/installer/build/common' make: *** [common] Error 2 the attached patch fixes the issue. I have not committed my changes though, since I want to be sure this patch is actually correct. Additionally, since the mingw32/issue.log and msys/issue.log files changes, how do I validate if they should be checked in or not? Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Charles W. <cwi...@us...> - 2010-09-10 02:45:29
|
On 9/9/2010 10:04 PM, Chris Sutcliffe wrote: > Looks like there is a bug in Makefile.comm.in that resulted in: > $ make ... > cp -p ../../../mingw-dist/common/issue.log tmp > cp: cannot stat `../../../mingw-dist/common/issue.log': No such file > or directory > the attached patch fixes the issue. I have not committed my changes > though, since I want to be sure this patch is actually correct. I'm not sure. I haven't had any problems, but then again, I haven't tried to rebuild from a totally clean build dir recently either. I'd hold off on that particular change for now, and just commit the xml and issue.log stuff by name. > Additionally, since the mingw32/issue.log and msys/issue.log files > changes, how do I validate if they should be checked in or not? Well...you really should not have ANY changes in msys/issue.log, because you didn't change any of those manifests (did you?). Basically, since you only changed mingw32-gdb and mingw32-runtime, you ought to see: --- mingw32/issue.log 6 Sep 2010 16:52:35 -0000 1.6 +++ mingw32/issue.log 10 Sep 2010 02:43:34 -0000 @@ -32,7 +32,7 @@ mingw32-bzip2.xml:2010090600 mingw32-cygutils.xml:2010090600 mingw32-expat.xml:2010052100 - mingw32-gdb.xml:2010052101 + mingw32-gdb.xml:2010091000 mingw32-gendef.xml:2010090600 mingw32-gettext.xml:2010090600 mingw32-libarchive.xml:2010090600 @@ -44,7 +44,7 @@ mingw32-pdcurses.xml:2010090600 mingw32-pexports.xml:2010090600 mingw32-popt.xml:2010090600 - mingw32-runtime.xml:2010052101 + mingw32-runtime.xml:2010091000 mingw32-xz.xml:2010090600 mingw32-zlib.xml:2010090600 And that's it. (When it doesn't work right, I have sometimes manually modified the issue log, removing all "unwanted" changes. Don't tell Keith. How many symlinks do you see in mingw32/unpublished/? -- Chuck |
From: Chris S. <ir0...@gm...> - 2010-09-10 03:00:01
|
On 9 September 2010 22:44, Charles Wilson wrote: >> Additionally, since the mingw32/issue.log and msys/issue.log files >> changes, how do I validate if they should be checked in or not? > > Well...you really should not have ANY changes in msys/issue.log, because > you didn't change any of those manifests (did you?). No, I didn't touch any other files other than runtime and gdb, yet.... > Basically, since you only changed mingw32-gdb and mingw32-runtime, you > ought to see: > > --- mingw32/issue.log 6 Sep 2010 16:52:35 -0000 1.6 > +++ mingw32/issue.log 10 Sep 2010 02:43:34 -0000 > @@ -32,7 +32,7 @@ > mingw32-bzip2.xml:2010090600 > mingw32-cygutils.xml:2010090600 > mingw32-expat.xml:2010052100 > - mingw32-gdb.xml:2010052101 > + mingw32-gdb.xml:2010091000 > mingw32-gendef.xml:2010090600 > mingw32-gettext.xml:2010090600 > mingw32-libarchive.xml:2010090600 > @@ -44,7 +44,7 @@ > mingw32-pdcurses.xml:2010090600 > mingw32-pexports.xml:2010090600 > mingw32-popt.xml:2010090600 > - mingw32-runtime.xml:2010052101 > + mingw32-runtime.xml:2010091000 > mingw32-xz.xml:2010090600 > mingw32-zlib.xml:2010090600 > > And that's it. (When it doesn't work right, I have sometimes manually > modified the issue log, removing all "unwanted" changes. Don't tell Keith. Looks like there is a bit of a problem, in that I see: $ cvs diff -u issue.log ir0...@mi...'s password: Index: issue.log =================================================================== RCS file: /cvsroot/mingw/mingw-dist/mingw32/issue.log,v retrieving revision 1.6 diff -u -r1.6 issue.log --- issue.log 6 Sep 2010 16:52:35 -0000 1.6 +++ issue.log 10 Sep 2010 02:57:00 -0000 @@ -23,29 +23,35 @@ # MinGW Project, accept liability for any damages, however caused, # arising from the use of this software. # - mingw32-autoconf.xml:2010090600 - mingw32-automake.xml:2010090600 + mingw32-autoconf.xml:2010091000 + mingw32-automake.xml:2010091000 mingw32-autotools.xml:2010090601 - mingw32-base.xml:2010071900 - mingw32-basic-bsdtar.xml:2010090600 + mingw32-base.xml:2010091000 + mingw32-basic-bsdtar.xml:2010091000 mingw32-binutils.xml:2010061600 - mingw32-bzip2.xml:2010090600 - mingw32-cygutils.xml:2010090600 + mingw32-bzip2.xml:2010091000 + mingw32-cygutils.xml:2010091000 mingw32-expat.xml:2010052100 - mingw32-gdb.xml:2010052101 - mingw32-gendef.xml:2010090600 - mingw32-gettext.xml:2010090600 - mingw32-libarchive.xml:2010090600 - mingw32-libiconv.xml:2010090601 - mingw32-libtool.xml:2010090600 - mingw32-make.xml:2010070100 - mingw32-mingw-utils.xml:2010090600 - mingw32-package-list.xml:2010090603 + mingw32-gcc3.xml:2010091000 + mingw32-gcc4.xml:2010091000 + mingw32-gdb.xml:2010091000 + mingw32-gendef.xml:2010091000 + mingw32-gettext.xml:2010091000 + mingw32-gmp.xml:2010091000 + mingw32-libarchive.xml:2010091000 + mingw32-libiconv.xml:2010091000 + mingw32-libtool.xml:2010091000 + mingw32-make.xml:2010091000 + mingw32-mingw-utils.xml:2010091000 + mingw32-mpc.xml:2010091000 + mingw32-mpfr.xml:2010091000 + mingw32-package-list.xml:2010091000 mingw32-pdcurses.xml:2010090600 - mingw32-pexports.xml:2010090600 - mingw32-popt.xml:2010090600 - mingw32-runtime.xml:2010052101 - mingw32-xz.xml:2010090600 - mingw32-zlib.xml:2010090600 + mingw32-pexports.xml:2010091000 + mingw32-popt.xml:2010091000 + mingw32-pthreads-w32.xml:2010091000 + mingw32-runtime.xml:2010091000 + mingw32-xz.xml:2010091000 + mingw32-zlib.xml:2010091000 # # $RCSfile: issue.log,v $: end of file > How many symlinks do you see in mingw32/unpublished/? Many: $ ls -1 mingw32-autoconf.xml.lzma mingw32-automake.xml.lzma mingw32-base.xml.lzma mingw32-basic-bsdtar.xml.lzma mingw32-bzip2.xml.lzma mingw32-cygutils.xml.lzma mingw32-gcc3.xml.lzma mingw32-gcc4.xml.lzma mingw32-gdb.xml.lzma mingw32-gendef.xml.lzma mingw32-gettext.xml.lzma mingw32-gmp.xml.lzma mingw32-libarchive.xml.lzma mingw32-libiconv.xml.lzma mingw32-libtool.xml.lzma mingw32-make.xml.lzma mingw32-mingw-utils.xml.lzma mingw32-mpc.xml.lzma mingw32-mpfr.xml.lzma mingw32-package-list.xml.lzma mingw32-pexports.xml.lzma mingw32-popt.xml.lzma mingw32-pthreads-w32.xml.lzma mingw32-runtime.xml.lzma mingw32-xz.xml.lzma mingw32-zlib.xml.lzma Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Charles W. <cwi...@us...> - 2010-09-10 03:29:53
|
On 9/9/2010 10:59 PM, Chris Sutcliffe wrote: > On 9 September 2010 22:44, Charles Wilson wrote: >>> Additionally, since the mingw32/issue.log and msys/issue.log files >>> changes, how do I validate if they should be checked in or not? >> >> Well...you really should not have ANY changes in msys/issue.log, because >> you didn't change any of those manifests (did you?). > > No, I didn't touch any other files other than runtime and gdb, yet.... > Looks like there is a bit of a problem, in that I see: >> How many symlinks do you see in mingw32/unpublished/? > > Many: It looks like your sync-to-published step didn't really work, and 'make' updated the issue.log for almost everything, created new .xml outputs, and lzma'ed them all. One way to "cheat" is to restore the issue.logs back to cvs HEAD, then *manually* populate {build}/mingw32/ and {build}/msys/ with all the .xml.lzma files downloaded from the web. Then 'touch' the {src}/mingw32/mingw32-gdb.xml and runtime.xml files. Then type 'make'. (I know Keith put a lot of work into this makefile scheme for creating the .xml.lzma's...but it does seem really very fragile...) -- Chuck |
From: Chris S. <ir0...@gm...> - 2010-09-10 18:37:21
|
On 9 September 2010 23:28, Charles Wilson wrote: > It looks like your sync-to-published step didn't really work, and 'make' > updated the issue.log for almost everything, created new .xml outputs, > and lzma'ed them all. > > One way to "cheat" is to restore the issue.logs back to cvs HEAD, then > *manually* populate {build}/mingw32/ and {build}/msys/ with all the > .xml.lzma files downloaded from the web. > > Then 'touch' the {src}/mingw32/mingw32-gdb.xml and runtime.xml files. > > Then type 'make'. (I know Keith put a lot of work into this makefile > scheme for creating the .xml.lzma's...but it does seem really very > fragile...) Would it be possible for you to address gdb and runtime files right now? I'm going to have to play around and figure out why this mechanism isn't working for me. Out of interest, do you use MSYS when maintaining the installer? I'm wondering if MSYS is playing a role in my issues, since as I understand it, Keith primarily works in Linux. Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Charles W. <cwi...@us...> - 2010-09-10 02:54:23
Attachments:
xml-updates2.patch
|
On 9/9/2010 9:17 PM, Chris Sutcliffe wrote: > On 9 September 2010 18:26, Charles Wilson wrote: >>> Additionally, is the '.tar' sufficient, or should it be >>> '.tar.lzma'? >> >> That's a very good question; I don't know. I suspect it should be >> .tar.lzma (or actually .tar.gz in the case of w32api), but many of the >> existing xml's don't include the compression schema. This is fine for >> <requires > specifications -- but it might not be so great for tarname >> attributes! > > Actually it is .tar.lzma as of the 3.15 release (at least for MinGW), > I updated the 'dist' target for MinGW to follow the newer naming > standard and preferred compression format. Well, in that case, you can't use a global <source> and <licence> tag for the w32api package. You have to do this: <component class="dev"> <release tarname="w32api-3.15-1-mingw32-dev.tar.lzma" > <licence tarname="w32api-%-mingw32-dev.tar.lzma" /> <source tarname="w32api-%-mingw32-src.tar.lzma" /> </release> <release tarname="w32api-3.14-mingw32-dev.tar.gz" > <licence tarname="w32api-%-mingw32-dev.tar.gz" /> <source tarname="w32api-%-mingw32-src.tar.gz" /> </release> </component> </package> >> I'd add the .gz in this case, but for the rest of the various xmls...no >> need to borrow trouble. Right now mingw-get doesn't use the <source> >> and <licence> entries, so...there's no hurry. > > As mention, .lzma is appropriate. See above (however, the mingwrt package is all .gz, all the time). -- Chuck |
From: Charles W. <cwi...@us...> - 2010-09-11 04:39:51
|
On 9/10/2010 2:37 PM, Chris Sutcliffe wrote: > Would it be possible for you to address gdb and runtime files right > now? For various values of the term "right now". Done. > Out of interest, do you use MSYS when maintaining the installer? I'm > wondering if MSYS is playing a role in my issues, since as I > understand it, Keith primarily works in Linux. That could be; I've been using cygwin to maintain mingw-dist (since there is no actual "compiling" involved), but msys/mingw for mingw-get (I know that's weird, but it works for me...) -- Chuck |
From: Chris S. <ir0...@gm...> - 2010-09-12 02:11:07
|
On 11 September 2010 00:38, Charles Wilson wrote: > On 9/10/2010 2:37 PM, Chris Sutcliffe wrote: >> Would it be possible for you to address gdb and runtime files right >> now? > > For various values of the term "right now". Ouch, sorry, just re-read what I had typed, didn't mean for it to come across the way it did. > Done. Thank you. >> Out of interest, do you use MSYS when maintaining the installer? I'm >> wondering if MSYS is playing a role in my issues, since as I >> understand it, Keith primarily works in Linux. > > That could be; I've been using cygwin to maintain mingw-dist (since > there is no actual "compiling" involved), but msys/mingw for mingw-get > (I know that's weird, but it works for me...) I should hopefully have time this coming week to try and figure out what's going on in terms of the issues I'm seeing. Cheers! Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |