From: Charles W. <cwi...@us...> - 2011-03-14 01:19:40
|
I did the following command, using 'mingw-get-0.2-alpha-1' mingw-get install msys-dvlpr and got the following warnings... Load catalogue: msys-system-builder.xml mingw-get.exe: *** ERROR *** gettext-0.17-2-msys-1.0.13-bin.tar.lzma: requires... mingw-get.exe: *** ERROR *** msys-libintl-%-msys-%-dll-8.tar: unresolved dependency (type 'eq') mingw-get.exe: *** ERROR *** msys-libintl-%-msys-%-dll-8.tar: cannot identify any providing package mingw-get.exe: *** ERROR *** please report this to the package maintainer mingw-get.exe: *** ERROR *** gettext-0.17-2-msys-1.0.13-dev.tar.lzma: requires... mingw-get.exe: *** ERROR *** msys-libgettextpo-%-msys-%-dll-0.tar: unresolved dependency (type 'eq') mingw-get.exe: *** ERROR *** msys-libgettextpo-%-msys-%-dll-0.tar: cannot identify any providing package mingw-get.exe: *** ERROR *** please report this to the package maintainer mingw-get.exe: *** ERROR *** gettext-0.17-2-msys-1.0.13-dev.tar.lzma: requires... mingw-get.exe: *** ERROR *** msys-libintl-%-msys-%-dll-8.tar: unresolved dependency (type 'eq') mingw-get.exe: *** ERROR *** msys-libintl-%-msys-%-dll-8.tar: cannot identify any providing package mingw-get.exe: *** ERROR *** please report this to the package maintainer But, the msys-gettext.xml manifest hasn't been changed in months, and it used to work fine. Plus, on visual inspection I can't see anything wrong with it. However, the upshot is, the following tarballs libgettextpo-0.17-2-msys-dll-0.tar.lzma libintl-0.17-2-msys-dll-8.tar.lzma did not get downloaded or installed during this phase. Oddly, /bin/msys-intl-8.dll DID get installed -- presumably during the original msys-base installation -- but I still don't have /bin/msys-gettextpo-0.dll /bin/msys-gettextlib-0-17.dll /bin/msys-gettextsrc-0-17.dll from the libgettextpo-0.17-2-msys-dll-0.tar.lzma installed. Help? I;m the package maintainer, so I'm supposed to fix this - but I don't understand what is wrong... -- Chuck |
From: Charles W. <cwi...@us...> - 2011-03-14 04:26:15
|
And another... There is some sort of confusion between [mingw32-]autoconf2.1-{bin,doc,lic} and [mingw32-]autoconf2.5-{bin,doc,lic} Everytime I try to isntall the latter, I get the former. Ditto for the 'list' command: $ mingw-get list autoconf2.5 2>/dev/null Package: mingw32-autoconf2.1 Subsystem: mingw32 ****^^^**** Components: bin, doc, lic autoconf2.1: Automatic Configure Script Builder (2.1x series) ------------------------------------------------------------- Autoconf is an extensible package of M4 macros that produce shell scripts to automatically configure software source code packages. These scripts can adapt the packages to many kinds of UNIX-like systems without manual user intervention. Autoconf creates a configuration script for a package from a template file that lists the operating system features that the package can use, in the form of M4 macro calls. This package provides the latest implementation of autoconf in the 2.1x series. FYI, there appears also to be confusion between automake1.11 and automake1.10, and between automake1.4, 1.5, 1.6, 1.7, 1.8, and 1.9 Basically, every command indicating automake1.11 gets "mapped" to automake1.10, and every command indicating automake1.x where x is 5...9, gets "mapped" to automake1.4 Should I file an official bug report, or am I doing something stupid? -- Chuck |
From: Keith M. <kei...@us...> - 2011-03-14 22:22:08
|
On 14/03/11 04:25, Charles Wilson wrote: > And another... This is a different issue. > There is some sort of confusion between > [mingw32-]autoconf2.1-{bin,doc,lic} > and > [mingw32-]autoconf2.5-{bin,doc,lic} > > Everytime I try to isntall the latter, I get the former. Ditto for the > 'list' command: > > $ mingw-get list autoconf2.5 2>/dev/null > > Package: mingw32-autoconf2.1 Subsystem: mingw32 > ****^^^**** I can reproduce this: $ ./mingw-get.exe list autoconf2.5 2>/dev/null Package: mingw32-autoconf2.1 Subsystem: mingw32 But curiously: $ ./mingw-get.exe list mingw32-autoconf2.5 2>/dev/null Package: mingw32-autoconf2.5 Subsystem: mingw32 gets it right. This points to a likely bug in the alias name matching performed by pkgXmlDocument::FindPackageByName(), which doesn't affect matching of the primary name. > Should I file an official bug report, I'll investigate anyway, but please do, so we have an easily traceable hook, on which to hang the follow-up discussion. > or am I doing something stupid? No, I don't think so. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2011-03-15 00:35:12
|
On 3/14/2011 6:21 PM, Keith Marshall wrote: > On 14/03/11 04:25, Charles Wilson wrote: >> And another... > > This is a different issue. Right. > I can reproduce this: > > $ ./mingw-get.exe list autoconf2.5 2>/dev/null > > Package: mingw32-autoconf2.1 Subsystem: mingw32 > > But curiously: > > $ ./mingw-get.exe list mingw32-autoconf2.5 2>/dev/null > > Package: mingw32-autoconf2.5 Subsystem: mingw32 > > gets it right. This points to a likely bug in the alias name matching > performed by pkgXmlDocument::FindPackageByName(), which doesn't affect > matching of the primary name. > >> Should I file an official bug report, > > I'll investigate anyway, but please do, so we have an easily traceable > hook, on which to hang the follow-up discussion. Done: https://sourceforge.net/tracker/?func=detail&aid=3212246&group_id=2435&atid=102435 -- Chuck |
From: Keith M. <kei...@us...> - 2011-03-14 22:01:31
|
On 14/03/11 01:19, Charles Wilson wrote: > I did the following command, using 'mingw-get-0.2-alpha-1' > > mingw-get install msys-dvlpr > > and got the following warnings... > > Load catalogue: msys-system-builder.xml > mingw-get.exe: *** ERROR *** gettext-0.17-2-msys-1.0.13-bin.tar.lzma: > requires... > mingw-get.exe: *** ERROR *** msys-libintl-%-msys-%-dll-8.tar: unresolved > dependency (type 'eq') > mingw-get.exe: *** ERROR *** msys-libintl-%-msys-%-dll-8.tar: cannot > identify any providing package > mingw-get.exe: *** ERROR *** please report this to the package maintainer And similarly, for... > mingw-get.exe: *** ERROR *** msys-libgettextpo-%-msys-%-dll-0.tar: Ouch! Strange that this is only now coming to light... > But, the msys-gettext.xml manifest hasn't been changed in months, and > it used to work fine. I suspect that it never did work fine. The code to generate those diagnostics is in src/pkgdeps.cpp, it was added by: > 2010-08-19 Keith Marshall > > Some dependency resolver enhancements and bug fixes. > > * src/pkgdeps.cpp ...snip... > (pkgXmlDocument::ResolveDependencies): Fix a block nesting error; > catch and diagnose unresolved dependencies; This has been in place since r0.1-alpha-3, and has not been changed since; prior to that, IIRC, there would have been some other fairly incomprehensible error message emitted. > Plus, on visual inspection I can't see anything wrong with it. I can... > Help? I;m the package maintainer, so I'm supposed to fix this - but > I don't understand what is wrong... Note that both dependencies are specified for: <release tarname="gettext-0.17-2-msys-1.0.13-bin.tar.lzma"> and are specified as: <requires eq="msys-libintl-%-msys-%-dll-8.tar" /> <requires eq="msys-libgettextpo-%-msys-%-dll-0.tar" /> Now, in resolving those, the "%" wildcards are expanded to match the REQUIRING package versions, i.e.: <requires eq="msys-libintl-0.17-2-msys-1.0.13-dll-8.tar" /> <requires eq="msys-libgettextpo-0.17-2-msys-1.0.13-dll-0.tar" /> but the actual corresponding releases are specified as: <release tarname="libintl-0.17-2-msys-dll-8.tar.lzma"> <release tarname="libgettextpo-0.17-2-msys-dll-0.tar.lzma"> which, lacking any msys version qualifier, do not match the specified requirements. > Oddly, > > /bin/msys-intl-8.dll > > DID get installed -- presumably during the original msys-base > installation Presumably because it was pulled in by another package, with a less specific requirement, e.g.: <requires eq="msys-libintl-*-msys-*-dll-8.tar" /> which CAN match the actual release specification. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2011-03-15 00:27:23
|
On 3/14/2011 6:01 PM, Keith Marshall wrote: > I suspect that it never did work fine. The code to generate those > diagnostics is in src/pkgdeps.cpp, it was added by: Strange. I could have SWORN I tested 'mingw-get install msys-dvlpr' at one point or another. Oh well... > Note that both dependencies are specified for: > > <release tarname="gettext-0.17-2-msys-1.0.13-bin.tar.lzma"> > > and are specified as: > > <requires eq="msys-libintl-%-msys-%-dll-8.tar" /> > <requires eq="msys-libgettextpo-%-msys-%-dll-0.tar" /> > > Now, in resolving those, the "%" wildcards are expanded to match the > REQUIRING package versions, i.e.: > > <requires eq="msys-libintl-0.17-2-msys-1.0.13-dll-8.tar" /> > <requires eq="msys-libgettextpo-0.17-2-msys-1.0.13-dll-0.tar" /> > > but the actual corresponding releases are specified as: > > <release tarname="libintl-0.17-2-msys-dll-8.tar.lzma"> > <release tarname="libgettextpo-0.17-2-msys-dll-0.tar.lzma"> > > which, lacking any msys version qualifier, do not match the specified > requirements. Ok... > ... a less > specific requirement, e.g.: > > <requires eq="msys-libintl-*-msys-*-dll-8.tar" /> > > which CAN match the actual release specification. Hm. Well, in this case, I need to match the gettext version number exactly, but I don't need to match the msys version number. (It'd be superfluous anyway, since "gettext-0.17-2" and ALL the (sub)components associated with that source would all have been built on the same version of msys). So, can I use: <requires eq="msys-libintl-%-msys-*-dll-8.tar" /> <requires eq="msys-libgettextpo-%-msys-*-dll-0.tar" /> that is, mix '%' and '*' for different fields? Also, it definitely appears to me that I chose poorly when naming the tarballs. I mean, really: libgettextpo-0.17-2-msys-dll-0.tar.lzma libintl-0.17-2-msys-dll-8.tar.lzma libasprintf-0.17-2-msys-dll-0.tar.lzma ^^^^^ vs. vvvvv gettext-0.17-2-msys-1.0.13-src.tar.lzma gettext-0.17-2-msys.RELEASE_NOTES.txt gettext-0.17-2-msys-1.0.13-ext.tar.lzma gettext-0.17-2-msys-1.0.13-lic.tar.lzma gettext-0.17-2-msys-1.0.13-doc.tar.lzma gettext-0.17-2-msys-1.0.13-dev.tar.lzma gettext-0.17-2-msys-1.0.13-bin.tar.lzma Note to self: for the next msys-gettext release, be consistent when naming the (sub)components. -- Chuck |
From: Keith M. <kei...@us...> - 2011-03-15 20:20:54
Attachments:
msys-gettext.xml.diff
|
On 15/03/11 00:27, Charles Wilson wrote: > So, can I use: > > <requires eq="msys-libintl-%-msys-*-dll-8.tar" /> > <requires eq="msys-libgettextpo-%-msys-*-dll-0.tar" /> > > that is, mix '%' and '*' for different fields? Yes, that's okay; it is probably the most logical way to write the requirements specs. However, you probably don't want to express the relationships to the source and licence files that way, so to make everything consistent, I think you need something like the attached. > Also, it definitely appears to me that I chose poorly when naming the > tarballs. ... > > Note to self: for the next msys-gettext release, be consistent when > naming the (sub)components. Sensible for the next release, yes, but probably not worth the pain of renaming the existing tarballs. My proposed patch uses download specs to work around it. Okay to commit? -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2011-03-15 20:45:29
|
On 3/15/2011 4:20 PM, Keith Marshall wrote: > On 15/03/11 00:27, Charles Wilson wrote: >> that is, mix '%' and '*' for different fields? > > Yes, that's okay; it is probably the most logical way to write the > requirements specs. However, you probably don't want to express the > relationships to the source and licence files that way, so to make > everything consistent, I think you need something like the attached. > >> Note to self: for the next msys-gettext release, be consistent when >> naming the (sub)components. > > Sensible for the next release, yes, but probably not worth the pain of > renaming the existing tarballs. My proposed patch uses download specs > to work around it. > > Okay to commit? Okay. -- Chuck |
From: Charles W. <cwi...@us...> - 2011-03-15 22:02:58
Attachments:
pkginfo.diff
|
On 3/15/2011 4:45 PM, Charles Wilson wrote: > On 3/15/2011 4:20 PM, Keith Marshall wrote: >> >> Okay to commit? > > Okay. And while you're at it, could you add an entry for the pkginfo element to the mingw-get manifest? (It's not a "component" of mingw-get itself, since it has a different basename, so...) Something like this: -- Chuck |
From: Keith M. <kei...@us...> - 2011-03-15 22:38:19
|
On 15/03/11 22:02, Charles Wilson wrote: > And while you're at it, could you add an entry for the pkginfo element > to the mingw-get manifest? Well, I had done with it just a bit too quickly to capture this... > (It's not a "component" of mingw-get itself, since it has a different > basename, so...) Something like this: ...but yeah, that looks good; I'll add it tomorrow. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2011-03-16 19:58:00
|
On 15/03/11 22:37, Keith Marshall wrote: > On 15/03/11 22:02, Charles Wilson wrote: >> And while you're at it, could you add an entry for the pkginfo >> element to the mingw-get manifest? > > Well, I had done with it just a bit too quickly to capture this... > >> (It's not a "component" of mingw-get itself, since it has a >> different basename, so...) Something like this: > > ...but yeah, that looks good; I'll add it tomorrow. All done now. -- Regards, Keith. |